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 <d...@dominicm.dev> wrote: > > John Kehayias <john.kehay...@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. >
