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
--
Sarah
