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

[Maxime Devos]

Liliana Marie Prikler schreef op wo 01-09-2021 om 15:33 [+0200]:
> 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? 

Not losing the revision is useful for things like 
<https://issues.guix.gnu.org/50072>,
to be able to determine the old revision.  (That's not about inheriting
packages though.)
> [...]

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

The commit is largely useless, ok.  If the (first few characters of) the
git commit/svn revision are removed from the version strings, it can be
removed from the proposed extended-version.

Otherwise, it would seem you wouldn't mind extended-version if it
only had the 'base version' and 'revision' field (in the guix sense,
not the SVN sense of revision), or am I misunderstanding here?

Geetings,
Maxime.

signature.asc
Description: This is a digitally signed message part