hi John!

I think it sounds like a swell addition to Guix, something that I would
definitely reach for time to time.

good stuff.

ez,
b

On Wed, Jul 13, 2022 at 2:26 AM Dominic Martinez <dom@dominicm.dev> wrote:

>
> 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.
>