From: "Jonathan McHugh" <indieterminacy@libre.brussels>
To: "Konrad Hinsen" <konrad.hinsen@cnrs.fr>,
"Katherine Cox-Buday" <cox.katherine.e@gmail.com>,
"Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: guix-devel@gnu.org, guix-science@gnu.org
Subject: Re: [Spam:]Re: “What’s in a package”
Date: Wed, 22 Sep 2021 15:44:35 +0000 [thread overview]
Message-ID: <9ae32bcfb6c45d1ef36fd6241580932e@libre.brussels> (raw)
In-Reply-To: <m1o88kwxbj.fsf@fastmail.net>
Hi Konrad,
Similarly I found the post excellent.
Your focus regarding a transition from exploratory to robust is important (though may have equal significance in the other direction?).
Would security experts have (understandable) criteria to prioritise choices for 'robust corridors' within an ecosystem of sourcefiles and encapsulated blobs?
====================
Jonathan McHugh
indieterminacy@libre.brussels
September 22, 2021 3:32 PM, "Konrad Hinsen" <konrad.hinsen@cnrs.fr> wrote:
> 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
> ---------------------------------------------------------------------
next prev parent reply other threads:[~2021-09-22 16:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 12:36 “What’s in a package” Ludovic Courtès
2021-09-21 18:38 ` Arun Isaac
2021-09-22 18:53 ` Pjotr Prins
2021-09-21 20:20 ` Katherine Cox-Buday
2021-09-22 13:32 ` [Spam:]Re: " Konrad Hinsen
2021-09-22 15:02 ` Katherine Cox-Buday
2021-09-22 18:20 ` Konrad Hinsen
2021-09-22 15:44 ` Jonathan McHugh [this message]
2021-09-22 19:44 ` zimoun
2021-09-23 7:36 ` Ludovic Courtès
2021-09-23 15:25 ` Katherine Cox-Buday
2021-09-24 9:04 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ae32bcfb6c45d1ef36fd6241580932e@libre.brussels \
--to=indieterminacy@libre.brussels \
--cc=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--cc=guix-science@gnu.org \
--cc=konrad.hinsen@cnrs.fr \
--cc=ludovic.courtes@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.