[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Maxime Devos |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Wed, 01 Sep 2021 18:39:20 +0200 |
User-agent: |
Evolution 3.34.2 |
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
- Re: Can we find a better idiom for unversioned packages?, (continued)
- 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
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?, Liliana Marie Prikler, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?,
Maxime Devos <=
Re: Can we find a better idiom for unversioned packages?, Jonathan McHugh, 2021/09/01
Re: Can we find a better idiom for unversioned packages?, Liliana Marie Prikler, 2021/09/01
Re: Can we find a better idiom for unversioned packages?, Maxime Devos, 2021/09/02
Re: Can we find a better idiom for unversioned packages?, Jonathan McHugh, 2021/09/02
Re: Can we find a better idiom for unversioned packages?, Liliana Marie Prikler, 2021/09/02
Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02