Re: Introducing ‘guix pack’

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Federico Beffa <beffa@ieee.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Federico,
>>
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> Say, developer A distributes such an archive A and developer B
>>> distributes archive B (a different program/library) and someone C
>>> installs both.
>>
>> Interestingly composability (what happens when you unpack both A and B
>> on the same system) is better than what you’d get with Docker: the
>> unpacked items that are identical are shared, and those parts that
>> differ don’t collide.
>
> Packs share identical items, but it becomes essentially impossible to
> remove one component out of many.

Yes, of course.  It’s really a frozen system snapshot.

>> The intended use case is mostly “one-off” packs where you just want
>> people to easily test something, as opposed to putting it in
>> production.  This was the case for the Guile 2.2.0 release.  In those
>> cases, people would essentially “rm -rf /gnu” when they’re done.
>
> If you provide an archive such as
> 'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main
> project page (especially without any warning about its intended
> purpose), I bet that many peoples will install it and keep it.  If more
> projects follow this example, we land to the above scenario where "rm
> -rf /gnu" is not practical at all.

I agree, there’s always a risk.  I think what we can do is communicate
about these risks, and avoid using distributing packs in situations that
make it too likely that people will keep the pack without ever
upgrading.

>> For code that is meant to be kept over time, I would recommend to either
>> use Guix, or to include Guix in the pack so that people can eventually
>> upgrade.
>
> This is clear to me, but there are many peoples who do not know about
> Guix, or just don't want it.  They may still be interested in, say,
> Guile 2.2.
>
> With the 'pack' command it seems to me that Guix is being promoted as a
> convenient development environment where at the end you can produce
> binary bundles for distribution on any system that it supports.  But,
> without providing at least a way to remove things, it seems to be
> heading toward a dangerous direction.

Sure.  I think it’s a handy but potentially dangerous tool.  In my view
the goal is not to promote Guix as a tool to make bundles, but rather
allow people to solve problems in specific circumstances, with the above
caveats.  Those caveats largely apply to other “app bundle” solutions,
and I’d argue that this one is “less bad” that most other bundling
solutions.

Thanks for your feedback!

Ludo’.