Re: Pinned/fixed versions should be a requirement.

[Attila Lendvai]

> For these reasons, I believe that pinned versions should be a
> requirement in libraries, always specifying the exact dependency, for
> example, `rust-serde-json-1.0.98`.


aiming a little higher, we could stop using module-global variables for 
pointing to packages (aka define-public), and with that eliminate one of the 
two, orthogonal and inconsistent (https://issues.guix.gnu.org/61292) package 
repositories, and only use the one-and-only reified package registry.

then, with some more work there could be:

 - a syntax extension to easily point to a package from scheme code;
   something like #^rust-serde-json@1.0.98

 - a "package GC" algorithm that collects and prints
   orphaned/unreferenced packages

 - "semantic" version pointers for situations where multiple versions
   of the same package cannot coexist in one profile, and/or dependent
   packages want to point to e.g. the latest, or the latest in a
   specific major version, or the "picked as current by the
   surrounding environment" (thinking here of things like the web of
   Gnome related packages that must all be compatible with each other,
   and only one instance is allowed to run at once).

this way we could be "rolling ahead" with the package definitions similarly to 
how derivations in the store are "rolling ahead" and unused ones get GC'd.

it would increase complexity in the sense that contributors would need to 
constantly keep an eye on moving forward the dependency pointers (unless 
"latest" or some other semantic reference is used as version for an input).

but in return it would increase resilience: a random update of a package would 
not break anything else that is downstream on the dependency chain. and i'm not 
only thinking of build errors here, but also subtle changes at runtime (e.g. 
how Chromium stopped being able to open the file open/save dialog while 
xdg-desktop-portal-gtk and xdg-desktop-portal-wlr were installed. their upgade 
broke Chromium, and it took me quite some time/annoyance to debug this).

i think this would also enable interesting features like being able to have two 
versions of Gnome alive and runnable in the same profile.

this would also open the path for something else that may or may not be worth 
it: the files holding the package definitions could be divorced from being full 
scheme module files, and turned into a text-based package database where 
algorithms (e.g. package import, GC) could reliably add and delete entries 
without human intervention (besides recording it as a git commit).

it's a whole other story that we shouldn't store source code as a string of 
characters, but instead admit that it's a graph, and store/edit it as such. 
that would implicitly resolve most of this problem, too, but i'm afraid we're 
not ready for that just yet.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“When you change the way you look at things, the things you look at change.”
        — Wayne W. Dyer (1940–2015)