Re: Pinned/fixed versions should be a requirement.

[Attila Lendvai <attila@lendvai.name>]

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