On Thu 19 Nov 2015 16:07, l...@gnu.org (Ludovic Courtès) writes: > My current inclination would be to not provide /usr/bin/env by default, > and instead let users add it if they want to, either using the > sledgehammer Ricardo suggests ;-), or simply with: > > ln -s /run/current-system/profile/bin/env /usr/bin/env > > We could document it, and/or even add a switch in ‘operating-system’ to > do that. > > How does that sound?
Fine with me. My use case is when working on Chromium, which has a bunch of scripts that are part of its development environment. Most of them start with /usr/bin/env, just a couple don't and I think those are bugs. In practice though that's something of a hack and what I really should go for is the --container thing... >> Alternately, I am not sure if this would work but we could make a form >> of "guix environment" which populates a profile that is mounted at /usr >> in a container. That would allow many more non-Guix tools to run. > > Technically ‘guix environment --container’ could create /usr, just like > it creates /bin/sh. Not sure if it’s a good idea, though. I think it is definitely interesting. The reason being, you might hack on something or have to deploy something and it's not part of Guix -- you don't want to rewrite the shebang lines for files in git that aren't build products. Being able to make a just-FHS-enough environment inside a container sounds to me like a useful tool to have for shimming Guix and the outside world, while also benefitting from Guix's reproducible environments, rollbacks, isolation, and so on. Andy
