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

[Xinglu Chen <public@yoctocell.xyz>]

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

On Tue, Aug 31 2021, Sarah Morgensen wrote:

> 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.
>
> 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.
>
> I do not have a specific solution in mind, but I think there must be
> one.  I do have a few half-baked ideas, but I'm curious what we can all
> come up with together.  Or maybe you'll just tell me I'm just being
> awfully picky :)
>
> [0] https://issues.guix.gnu.org/50286

I never felt like including the commit id in the version of a package
was useful; e.g., just seeing the first seven characters of the commit
id doesn’t really tell me anything about the version.  I think it is
more useful to put the date of the commit in the version; Nixpkgs does
something like this[1].  I have started to put the date of the commit in
a comment, just to make it easier for people to know how old it commit
is; otherwise, one would have to find the VCS repo and find the commit
just to see how old the commit is.

--8<---------------cut here---------------start------------->8---
(define-public foo
  ;; No tags; commit from YYYY-MM-DD.
  (let ((commit "COMMIT-ID")
        (revision "1"))
    (package
      ...)))
--8<---------------cut here---------------end--------------->8---

Instead of having showing something like

  foo-1.0.0-1.cabba9e

users would see

  foo-1.0.0-1.2021-01-31


Just my 2€  :-)

[1]: <https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/accessibility/dasher/default.nix>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]