Erik Sipsma

> In the particular case of SSHFS, we are using network access to mount the share - what case are you thinking of where this would be specific to a...

> Are these particular infrastructure-specific concerns worth moving below the line, or are they more like the other "purity tradeoffs" you mentioned, like hostnames that may or may not resolve...

> Is the idea that sshfsVolume() would only be available to external clients, kind of like host()? Yes > How would these new functions be called? From the Dagger CLI?...

> What does "needing to use shell" entail? In the model we currently use, Jenkins invokes a single dagger function (using dagger call) and passes in the git repository and...

> What we were discussing here was: should we implement a similar convenience for arguments of type CacheVolume, where URIs like sshfs:// are supported, and if so, what should the...

> Bikeshedding the API design for new volume constructors (I think we should implement it regardless, unlike secret providers where we'll have to retrofit - do you agree?) Yeah I...

Local dev docs can be found [here](https://github.com/dagger/dagger/blob/main/.dagger/README.md), but will outline some more pointers specific to this effort. cc @IljaKroonen and team ## Implementation Will give a high-level outline here, obviously...

> 1. The sshfs ideally shouldn't be container-based API. The reason is that pulling a large filesystem and unmounting before running the next container can be expensive compared to mounting...

I agree we need to do something like this, but do want to note that the fact that cache volumes can be shared across modules is highly beneficial to performance...

Yeah SGTM, coincidentally everything required to implement enforcement of only using cache volumes you create or are explicitly passed is also what's required to safely pass sockets around (https://github.com/dagger/dagger/issues/6747), which...