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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

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

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?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]