John Kehayias <john.kehayias@protonmail.com> writes:

> First, I wanted to ask how people feel about such a feature. Obviously, one use
> is to run pre-built binaries (isolated!), but this is also handy for setting up
> development environments when not able (or wanting) to with Guix packages only.
> For example, using the rustup [0] scripts, pretty much anything JS, or just
> following typical Readme instructions to try out something new before packaging.
> I won't debate the details here other than to say this topic comes up with Guix
> and I think it is yet another useful tool for guix shell and containers.

Absolutely! I usually have to resort to Docker containers when building
something that doesn't support GuixSD, so being able to work with them
through Guix would be amazing.

> What about other uses for this container, like providing an isolated environment
> to build and run software we can't do fully with bootstrap and sources (like
> JS)? Could this become some stop-gap to allow people to work with these
> ecosystems in a more controlled way within Guix? Or an alternative build
> environment? Not entirely sure what this could mean, just thinking out loud.

I think an interesting idea would be to allow packages to transparently
run in the FHS container (i.e. a shim that turns 'x' into 'guix shell
--fhs-container x -- x'). That way software incompatible with GuixSD in
a way too difficult to patch could be still be packaged and used
transparently, albeit with a significant performance cost.

Even if packages in Guix proper don't use it, it could be useful for
third-party channels or end-users to whip up packages.

Thanks so much for this; I've been thinking about getting around to this
feature for quite a while.