[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Spam:]Re: “What’s in a package”
From: |
Katherine Cox-Buday |
Subject: |
Re: [Spam:]Re: “What’s in a package” |
Date: |
Wed, 22 Sep 2021 10:02:55 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Konrad Hinsen <konrad.hinsen@cnrs.fr> writes:
> What is so far insufficiently supported by computing technology is the
> necessary transition from "fast" to "robust".
This is really a large problem in the industry. Especially since in most
circles moving fast is considered the preferred way to do things. SaaS and
abstractions are endemic, and while helpful to get things going, it can lead to
precarious systems with interdependencies and risks that are not fully
understood or appreciated.
The "fast" path does allow people to test out new ideas very quickly, but there
is a hidden cost. As we've seen these past years with COVID-19 and the world's
supply chains, efficiency has some kind of inverse relationship with
robustness. If you go too far down the path of efficiency, you are not very
flexible, and you're building sand castles.
It's for this reason I appreciate having "robust" software underneath my sand
castle. At least I know only so much can crumble :)
> 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.
I really like this framing. How can we support every step of the continuum with
a gentle pull towards robustness? That sounds like something to strive for.
>> 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.
I want to be careful here in what I suggest. I think it is very important that
Guix remain a bastion of robust software with very high standards. I don't want
to see the PyPi PyTorch packages of the world in Guix. I /do/ want to see
tooling in Guix that allows users to package and utilize these things as
first-class primitives in the Guix world.
In other words, let me create beautiful and terrible things, but don't let me
unleash them on the world.
So with your example: make it really easy to transform that PyPi package into a
terrible Guix primitive of some kind, but don't let me commit it to Guix proper.
> 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.
This kind of stuff really excites me. If we could build tooling that somehow
moves things along the continuum, that would really be something. Maybe
interactive software that introspects how a package is written and behaves at
runtime (in a container?) and utilizes the homoiconicity of scheme to suggest
modifications of the package, or next steps. E.g. expand the linter to suggest
things like documentation, or to identify at what point on the continuum the
package might currently be, and how to move forward. Does the package vendor
binaries? Does Guix have any packages that look like those binaries? What does
the packages binaries want to link to? What paths does it try and access when
run?
Speaking of industry, I don't think we leverage software to build software
enough.
And by the way, none of those ideas would be possible if Guix weren't such a
robust and sane ecosystem.
--
Katherine
- “What’s in a package”, Ludovic Courtès, 2021/09/20
- Re: “What’s in a package”, Arun Isaac, 2021/09/21
- Re: “What’s in a package”, Katherine Cox-Buday, 2021/09/21
- Re: [Spam:]Re: “What’s in a package”, Jonathan McHugh, 2021/09/22
- Re: “What’s in a package”, zimoun, 2021/09/22
- Re: “What’s in a package”, Ludovic Courtès, 2021/09/23