Feature Request: Allow mounting path to a different path within container about toast HOT 12 CLOSED

Just created a PR, please take a look @stepchowfun. Thanks!

from toast.

Hi @NOBLES5E, thanks for filing this feature request. I agree that it seems like a useful feature.

However, I personally have never needed this, since generally I use input_paths to copy the files from a project into the container with the same directory structure. So I'd be curious to learn more about your use case—perhaps you are using Toast in a different way than I do (which would be interesting to learn about!).

Also, I just wanted to confirm: do you know about the location field which allows you to change the base path for all files copied into the container? I rarely use this as well (since the default location is usually as good as any), but it can be useful if some program expects the files to be in a particular location for some reason (e.g., nginx likes to serve files from /usr/share/nginx/html/ by default).

I can't promise any particular timeline or guarantee about this feature being implemented. For now I will leave the issue open for discussion.

from toast.

Thanks! In my case I need to mount a different host directory to target/ directory in the container to do incremental build. Are there any better solutions?

from toast.

Oh my mistake—I seem to have misread and thought it was about input_paths rather than mount_paths.

Just checking: Did you know mount_paths can be relative? On the host they are relative to the directory containing the toastfile, and in the container they are relative to the location of the task. Does that address your use case, or do they need to be totally distinct paths?

from toast.

Yes, but I have multiple build tasks, and they use different directories like this:

task    host              container
task1   target-task1/     target/
task2   target-taks2/     target/
task3   target-task3/     target/

Currently I can create a symlink in the container manually like

task    host              container
task1   target-task1/     target/ -> target-task1/
task2   target-taks2/     target/ -> target-taks2/
task3   target-task3/     target/ -> target-taks3/

But it feels awkward 😢

from toast.

I see—thanks for explaining. If I may ask, why do the 3 target-taskN directories need to be distinct on the host? Or why do they need to map to the same directory in the container? I'd be curious learning about what build system/language/toolchain you're using that calls for this arrangement.

from toast.

Yes they need to be distinct. They are used to compile the program under different system environments (different rustc, and system libraries like libc). If we use only one directory, compiler will raise error when doing incremental compilation.

from toast.

@stepchowfun Do you think we should add this feature? I can help create a pull request implementing this if needed.

from toast.

The only thing I'm unsure about is: which of the following fields would support this feature?

• input_paths
• mount_paths
• mount_readonly
• output_paths
• output_paths_on_failure

Functionality wise, I think it would make sense for all of them to support this feature for consistency. But I expect it will be much easier to implement this for the mount_ fields than the others, and then the output_ fields would be the next easiest to implement, and input_paths would probably be the most difficult.

I am grateful for your willingness to contribute (thank you!). To avoid any potential confusion down the road, maybe we can align on the plan first? Which of those would you plan to implement?

from toast.

I was thinking about mount_ fields since that is what I need now and seems easy to do. Not sure about how to implement other fields yet.

from toast.

Ok, that sounds reasonable to me.

from toast.

Fixed by #361 and #365.

from toast.