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

[Liliana Marie Prikler]

Hi

Am Dienstag, den 31.08.2021, 23:20 +0200 schrieb Maxime Devos:
> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]:
> > Hello Guix,
> > 
> > Currently, there are about 1500 packages defined like this:
> > 
> > --8<---------------cut here---------------start------------->8---
> > (define-public sbcl-feeder
> >   (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
> >         (revision "1"))
> >     (package
> >       [...])))
> > --8<---------------cut here---------------end--------------->8---
> > 
> > I feel like there are some issues with this idiom (in no particular
> > order):
> > 
> > 1. When converting between this idiom and regularly versioned
> > packages, the git diff shows the whole package changing because of
> > the indentation change.
If you are worried about that in a frequently changing package, you
could set both to *unspecified* or #f instead, which would cause any
reference to them in a string manipulation context to fail.  I don't
think that such transitions are too frequent, though, as the point is
rather to discourage them where not absolutely necessary and to use
upstream releases instead.

> > 2. We cannot get at the source location for the definition of
> > 'commit' or 'revision'.  This would be useful for updating these
> > packages with `guix refresh -u`.  There is a proposed patch [0] to
> > work around this, but it *is* a workaround.
Other versioning idioms would also be workarounds, wouldn't they?

> > 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.
What purpose would extracting those serve however? 

> > 4. Horizontal space is at a premium, and an extra two spaces here
> > and there add up.  (Personally, I think we could do with a
> > define-public-package macro to save another two spaces, but that's
> > for another day...)
The worst offenders in horizontal space typically come from the
packages themselves and going from 79 to 81 in select outliers is AFAIU
acceptable.

> > 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.
This concerns packages without a public release, many of which never
make one in the belief that commit hashes are valid versions (they are
not).

> Suggestion: extend the 'version' field.  More specifically,
> introduce a new record <full-version>, like this:
> 
> (define-record-type* <extended-version> extended-version make-
> extended-version
>   extended-version? this-version
>   ;; something like 1.2.3 (TODO better name)
>   (base extended-version-base)
>   (revision extended-version-revision)
>   (commit extended-version-commit))
> 
> (define (version->string version)
>   (match version
>     ((? string?) version)
>     (($ <extended-version> ...) code from original git-version  and
> hg-version)))
> 
> ;; TODO:
> ;; adjust git-file-name and hg-file-name to accept <extended-version> 
> records
> ;; (as well as the ‘old style’ for compatibility)
> 
> To be used like:
> 
> (define-public sbcl-feeder
>   (name "sbcl-feeder")
>   (version (extended-version
>              (base "1.0.0")
>              (revision 1)
>              (commit "b05f517d7729564575cc809e086c262646a94d34")))
>  (source
>   (origin
>     (method git-fetch)
>     (uri (git-reference ...)
>            (url ...)
>            ;; git-reference needs to be extended to retrieve the
> commit from the version
>            (version version)))
>     (file-name (git-file-name "feeder" version))
>     (sha256 ...)))
>  [...])
> 
> That should address 1,2,3,4 and 5.
> 
> One problem with this approach is that most users of 'package-
> version' expect it to return a string.  Maybe adding a keyword
> argument '#:full-version? #t/#f' defaulting to #f would work?
I think the bigger problem here is that you're moving bits meant for
the origin into the version only to be able to point to the version
from the origin.  Even accepting that you could use "commit" or a
separate field to encode SVN/CVS revision numbers instead of hashes,
everything beyond the revision number is basically pointless from a
versioning scheme POV and only really useful to fetch the source code. 
As Xinglu Chen points out, a commit hash encodes remarkably little on
its own.

Perhaps we could make the point that origins can be versioned just like
packages can and should think about where the version field really
belongs.  I think having a per-origin version field and making it so
that the package defaults to the origin version unless the package
itself has a version specified, might be a better solution
philosophically speaking.  Technically, it would only solve 1, 4 and 5,
but there's a separate workaround for 2 and I don't really think 3 to
be that big of an issue.

Regards