Re: “What’s in a package”

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Tue, 21 Sep 2021 at 15:20, Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

>                                                              I.e.,
> when trying to achieve a goal, it is a pain to package things that
> aren't yet packaged, but what I get in return are sane environments,
> deployments, and meta-data about all of these.

I concur! :-)

> This is perhaps a rehash of the "worse is better"[2] conversation, but
> I often struggle with deciding whether to do things the "fast" way, or
> the "correct" way. I think when your path is clear, the correct way
> will get you farther, faster. But when you're doing experiments, or
> exploratory programming, being bogged down with the "correct" way of
> doing things (i.e. Guix packages) might take a lot of time for no
> benefit. E.g. maybe you end up packaging a cluster of things that you
> find out don't work out for you. Of course the challenge is: if you
> choose the fast way, and it works out, do you got back to do it the
> correct way so that you're on sound footing?
>
> Bringing this back to Guix, and maybe the GNU philosophy, it has been
> very helpful for me to be able to leverage the flexibility of Guix to
> occasionally do things the "fast" way, perhaps by packaging a
> binary. Paradoxically, it has allowed me to stay within the Guix and
> free software ecosystem. In my opinion, flexibility is key to growing
> the ecosystem and community, and I would encourage Guix as a project
> to take every opportunity to give the user options.

Long time ago, I watched this badly recorded video [1] about “Haskell is
useless”.  I reframe for packages the exposed double-axis:

 useful  | trad-pkg ~~>    Nirvana
         |                 ^
         |                 | Guix
useless  |               
         -----------------------
          unsafe            safe

where ’unsafe’ vs ’safe’ could read ’fast’ vs ’robust’; and trad-pkg
reads apt, conda, spack, yum, etc.


1: <https://youtu.be/iSmkqocn0oQ>


Cheers,
simon