Re: Feature requests

[Joshua Marshall <j.marshall@arroyo.io>]

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

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>

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