Re: Feature requests

[Julien Lepiller <julien@lepiller.eu>]

[-- Attachment #1: Type: text/plain, Size: 7016 bytes --]

Mh… so I'm still not sure if that's an actual issue. You can always install two software that rely on different versions of a library. I guess in your example it only means that we need two libc packages, right? As long as you're able to define a package recipe for everything you want, using different versions of the same package is fine, because they are different inputs, so they have a different store path.

A package built with glibc 2.10 well reference that old libc and never know about the newer ones even if they're installed in the same profile, as long as the libc is not a propagated-input.

I still don't see an incompatibility that's not solved by guix. With python packages however that's very different because inputs are propagated. If python could reference its dependencies directly, it would have been just fine, but indeed two incompatible dependencies will end up in your profile. We can wrap python software already though, so it ignores the environment and picks only the dependencies it was built with. That's not always the best solution though. Maybe you can give as a concrete example for the python case? Then we will be able to help you better and come up with the right solution for your problems :)

From what you describe I still think that guix environments are what you want: if you have python-foo and python-bar that both depend on incompatible versions of python-baz, you can create an environment for python-foo:

guix environment --ad-hoc python python-foo --pure

In which you can use python-foo but not python-bar, and a similar command will give you a similar environment where you can run python-bar but not python-foo.

If you suppose these python packages provide a foo and a bar command, you could also do:

alias bar=guix environment --ad-hoc python python-bar --pure -- bar

And the same for foo, and you would have isolated environments. You can also use that to control what python-foo has access to at runtime. For instance if it can use python-foobar at runtime, you would do:

alias foo=guix environment --ad-hoc python python-foo python-foobar --pure -- foo

And the foo command now has access to its runtime dependency (if it wasn't already declared at build time).

HTH

Le 23 mars 2019 15:01:24 GMT+01:00, Joshua Marshall <j.marshall@arroyo.io> a écrit :
>I'm still getting my feet wet as it were.  As a more relatable example,
>lets use glibc.  Say an application developed in 2000 had bug
>compatibility
>with glibc at that time.  Then say that bug is fixed circa 2005 and
>another
>introduced.  Then have in 2010 an application made with bug
>compatibility
>for the 2005 version.  Now, if both of these applications were
>co-installed
>at most one could work due to bug compatibility.  Now I'm not saying
>this
>is good practice or even common, but this type of thing happens at my
>work
>frequently enough that we have a whole toolset dedicated to managing
>just
>this problem.  It gets far more severe in the python world.  To cope
>with
>such poorly behaved programs, greater levels of isolation are needed,
>like
>each individual thing running in its own Docker container.  But
>sometimes
>even this isn't enough as the dependencies will have a similar problem
>and
>so such isolation measures need to be recursively applied.  It gets
>messy.
>
>On Fri, Mar 22, 2019 at 6:30 PM Julien Lepiller <julien@lepiller.eu>
>wrote:
>
>> Hi!
>>
>> I'm not sure what you mean when you talk about incompatible packages,
>> maybe you could give a concrete example? I don't think there's
>anyching
>> that couldn't go to the store at least… So you can always create
>separate
>> profiles.
>>
>> That said, I think people are working on improving the network
>support in
>> guix environment containers, and I think it's a good thing :). I'm
>not sure
>> about cgroups, but our environments already provide quite a bit of
>> isolation. Have you tried "guix environment --ad-hoc python
>--container"
>> for instance? There are more options to control what parts of the
>file
>> system is available inside the container.
>>
>> Le 22 mars 2019 18:47:19 GMT+01:00, Joshua Marshall
><j.marshall@arroyo.io>
>> a écrit :
>>>
>>> Hello all,
>>>
>>> I was told in IRC to post my possibly unreasonable feature requests
>here.
>>>
>>> I've been thinking more on what Guix might be able to do, and what
>would
>>> make it more useful for a few of my past jobs.  I'd like to see it
>take on
>>> the ability to have a per-installation target cgroup, network
>namespace,
>>> and filesystem chroot settings set with defaults which are
>overridable at
>>> invocation.  In this way, a user could install and use packages with
>>> mutually incompatible dependencies (I talked about this with a few
>people
>>> on IRC) like what happens with python.  If this kind of
>functionality were
>>> added, it would largely supplant Docker, virtualenv, pip, poetry,
>apk,
>>> pacman, and probably a few other tools at my company which are there
>just
>>> to handle this kind of frailness.  From this, I could also see an
>entry
>>> point to adding build module support to start to replace tools like
>Make,
>>> CMake, Meson, Bazel, and so on.
>>>
>>> These expand the scope of Guix quite a bit, but I think these are
>needed
>>> for it to really feel logically complete.  Does all this make sense?
>>>
>>>
>>> Please be advised that this email may contain confidential
>information.
>>> If you are not the intended recipient, please notify us by email by
>>> replying to the sender and delete this message. The sender disclaims
>that
>>> the content of this email constitutes an offer to enter into, or the
>>> acceptance of, any agreement; provided that the foregoing does not
>>> invalidate the binding effect of any digital or other electronic
>>> reproduction of a manual signature that is included in any
>attachment.
>>>
>>> <https://twitter.com/arroyo_networks>
>>> <https://www.linkedin.com/company/arroyo-networks>
>>> <https://www.github.com/ArroyoNetworks>
>>>
>>
>> --
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser ma
>> brièveté.
>>
>
>-- 
>
>
>
>Please be advised that this email may contain confidential information.
>
>If you are not the intended recipient, please notify us by email by 
>replying to the sender and delete this message. The sender disclaims
>that 
>the content of this email constitutes an offer to enter into, or the 
>acceptance of, any agreement; provided that the foregoing does not 
>invalidate the binding effect of any digital or other electronic 
>reproduction of a manual signature that is included in any attachment.
>
>
> 
><https://twitter.com/arroyo_networks>   
><https://www.linkedin.com/company/arroyo-networks>   
><https://www.github.com/ArroyoNetworks>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

[-- Attachment #2: Type: text/html, Size: 9594 bytes --]