[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Xinglu Chen |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Wed, 01 Sep 2021 12:55:54 +0200 |
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>
signature.asc
Description: PGP signature
- Re: Can we find a better idiom for unversioned packages?,
Xinglu Chen <=
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/04
- Re: Can we find a better idiom for unversioned packages?, Ludovic Courtès, 2021/09/08