Re: [Spam:]Re: “What’s in a package”

[Konrad Hinsen]

Hi Katherine and Ludo,

> I appreciate this post very much. Setting aside questions of freedom,

+1

> 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

Exactly. Most software engineering tools situate themselves somewhere on
the "fast" vs. "robust" scale, and defend their position as the one and
only Good Thing. Guix is at the "robust" end of the scale in the
software management category. And that's what I want for most of the
software I use, i.e. everything I don't hack on myself. Which is why I
like Guix :-)

What is so far insufficiently supported by computing technology is the
necessary transition from "fast" to "robust". There are a few
exceptions, such as programming language with gradual typing. In most
situations, moving software from exploratory to robust involves a lot of
rewriting, often manually, with no tooling support.

> 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.

+100 :-)

There is a lot we can improve here. Tutorials would be a good start.
Example: How do you package a binary in Guix? In particular, how do you
deal with binaries that have binary dependencies that they expect in
/lib etc.? A next step would be tool support: Grab whatever PyPI offers,
even if it's only binary wheels, and turn that into a Guix package.

Another aspect would be supporting software development moving from fast
to robust. Suppose I have software I compile by hand, or via a simple
Makefile, somewhere in my home directory. How do I go from there to (1)
a quick-and-dirty Guix package, then (2) a very basic publishable Guix
package and finally (3) a Guix package with tests and documentation?
The path should be supported by various tools, from automatic rewriting
to debugging. As an example, something I have wished for more than once
is the possibility to run the individual build steps of a Guix package
under my own account in my home directory, for debugging purposes.

Konrad
-- 
---------------------------------------------------------------------
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: konrad DOT hinsen AT cnrs DOT fr
http://dirac.cnrs-orleans.fr/~hinsen/
ORCID: https://orcid.org/0000-0003-0330-9428
Twitter: @khinsen
---------------------------------------------------------------------