[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can we find a better idiom for unversioned packages?

From: Ludovic Courtès
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Wed, 08 Sep 2021 23:28:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)


Sarah Morgensen <> skribis:

> Currently, there are about 1500 packages defined like this:
> (define-public sbcl-feeder
>   (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
>         (revision "1"))
>     (package
>       [...])))
> I feel like there are some issues with this idiom (in no particular
> order):

I’m late to the party but I’ll complement previous answers.  :-)

> 1. When converting between this idiom and regularly versioned packages,
> the git diff shows the whole package changing because of the indentation
> change.

One can use ‘git diff -w’ to work around that (or the newfangled
Diffstatic tool.)

> 3. Packages inheriting from it lose the definitions.  For actual fields,
> we have e.g. `(package-version this-package)`, but we have no equivalent
> for these.

Right, these pieces of information are not “first-class”, except in the
‘git-reference’ record (or similar) for the commit ID.  Do you have
examples in mind where it’s insufficient?


> 5. The closest thing we have to a standardized way of generating
> versions for these packages is `(version (git-version "0.0.0" revision
> commit))`.  We can do better than that boilerplate.

I can sympathize with the feeling, but I’m not sure what to do.  A
‘vcs-version’ record as Maxime proposes seems a bit overkill to me (and
it would probably have an impact on performance, build times, and

> 6. Not a direct complaint, but I feel like the overall package interface
> was designed before straight-from-vcs unversioned packages were so
> common, and so this idiom developed organically to work around that.

Sure, though “straight-from-vcs” and “unversioned” are two different
things: I’m fine with the former, but the latter equates to upstream
telling its users “go find a revision that works for you”.  I think
releases still make sense for any non-trivial piece of software.

As noted in the manual (info "(guix) Version Numbers"), packages built
from arbitrary commits were supposed to be exceptional.  Perhaps the
reason we’re having this conversation now is that development practices
are evolving towards what looks like chaos.  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]