#[WIP] dagger watch by aluzzardi · Pull R...
valid jackal
Yes but there is an important case why run options would be better in my opinion. Let's say the host mounts a large NFS. If the mount is used, the NFS from the host would be copied to the container, which can later be watched. However, that copy is not necessary in this case and would be a large performance hit compared to the run option where only during a container run, the volume gets mounted to the container.
Please forgive me if I'm wrong, but while playing with the source code, all volumes would be copied to the container. In case of large folders, the runtime option would be a better fit
valid jackal
Hey @icy barn , when you find time please let me know what you think.
icy barn
i'm relatively new here, not the right person to ask. many other folks are on PTO for the holidays but will start trickling back in on monday.
that said, the utility of bind mounts is mega-obvious and additionally I think everybody agrees that we'd love to add support for live development with watches, language-native live reloads, etc. bind-mounts are certainly the easiest and best way to do that when the client and engine are running on the same linux machine.
the hesitance and delay here is likely around multi machine setups, like we're feeling around for an approach that can also feasibly support macos clients with same-machine-linux-vms as well as setups where you want to us an iaas-provisioned machine as remote compute
#maintainers message linking up your first message for provenance
rotund ice
last I discussed with @velvet elk and @marsh copper , there was a preference for solving the problem without "raw" bindmount, but by implementing a super-streamlined watcher, where the service is efficiently restarted as local changes are synced.
you still need file sync etc under the hood. but it's exposed differently than "pretend bind mounts" in docker
velvet elk
Hey @valid jackal -- AFAIK the main reason (at least, one of the main reasons) we don't support that is it's not supported under the hood by buildkit because of content addressability -- e.g. since bind mounted volumes would not be part of the "content hash", then buildkit would have no idea whether the contents changed or not, in which case it would either have false positive caching (not re-run the operation even though the underlying bind mounted content changed), or caching would always be disabled
This is pretty old understanding, not sure if that's still up to date. /cc @marsh copper