unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <leo.prikler@student.tugraz.at>
To: Maxime Devos <maximedevos@telenet.be>,
	Sarah Morgensen <iskarian@mgsn.dev>,
	 guix-devel@gnu.org
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Wed, 01 Sep 2021 20:34:44 +0200	[thread overview]
Message-ID: <27af2d4efec4ced1e8411b1d993dbc8112d26cb7.camel@student.tugraz.at> (raw)
In-Reply-To: <1e58de895f638d897ea89647344ef24c40ea3ec2.camel@telenet.be>

Am Mittwoch, den 01.09.2021, 18:39 +0200 schrieb 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.)
Isn't that addressed by addressing the second point, though?  Like, if
you know the source location of the revision, you can read it back to
get the value itself (or possibly even access it as-is), no?
> > [...]
> > > 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?
That was not my suggestion, but let's entertain the idea, shall we?  In
that case, we would discard the commit part from the version field,
which might not be everyone's tea, but I'm more or less indifferent as
to whether to include the hash there or not – after all, even if it was
lacking, we'd quickly get it through inspecting the package
description.  If we simply didn't capture the hash at all except inside
the commit field of the origin, we would gain 1, 4 and 5 so the
question is whether we should have an extended version so as to update
the revision more easily...

My personal answer to this might be a disappointing one, as in that
case I believe we wouldn't even need procedures like git-version to
form them, but could instead use <upstream-version>-<guix-revision> as
a mere convention like many more popular distros already do.  If the
dash is overused for that, we could also use a different symbol, though
perhaps there's not that many on a typical US keyboard to reserve one
as a revision delimiter.

Making our rando commit git versions look like such other distro
versions does come at a disadvantage though, particularly when we look
at it through the lense of someone not used to Guix' versioning scheme.
Instead of telling us "yeah, this is the Nth time we picked a rando
commit since the last release and this time it's de4db3ef", users
coming from such distros would assume "oh well, this is still good ol'
1.0 with some more patches applied".  So while the commit itself does
not give us any particularly useful information (unless you're that
person who uses this part of the version string to look the commit up
on hubbucket), especially not when thinking in the context of
versioning scheme, it does provide the existential information of "hold
on, this is not a release commit, it's something else" and might thus
direct users to be a little more attentive when they'd otherwise go
"yep, upstream considers this solid and Guix considers it even more
solid, so it's the solidest".  Note, that this can be overcome both by
teaching/learning about it and by using a special sigil as mentioned
above.

All in all, I don't think putting too much "opinion" in the version
field by storing it as a record is a good idea.  It's fine if it's just
a string that can be parsed/version-compared.  We could also make it a
list like Emacs does and like we use internally, though I'm not too
certain of what the benefit of that would be at the cost of breaking
pretty much everything (and probably putting in some opinions as to
what is to be delimited by dots and what by dashes).

Regards



  reply	other threads:[~2021-09-01 18:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 19:57 Can we find a better idiom for unversioned packages? Sarah Morgensen
2021-08-31 21:20 ` Maxime Devos
2021-09-01 12:11   ` Xinglu Chen
2021-09-01 16:29     ` Maxime Devos
2021-09-01 13:33   ` Liliana Marie Prikler
2021-09-01 16:39     ` Maxime Devos
2021-09-01 18:34       ` Liliana Marie Prikler [this message]
2021-09-02 14:09         ` Maxime Devos
2021-09-02 14:20           ` Liliana Marie Prikler
2021-09-02 14:34             ` Maxime Devos
2021-09-01 19:48       ` Jonathan McHugh
2021-09-01 21:47         ` Liliana Marie Prikler
2021-09-02 13:32           ` Maxime Devos
2021-09-02  7:53         ` Jonathan McHugh
2021-09-02  9:25           ` Liliana Marie Prikler
2021-09-01 10:55 ` Xinglu Chen
2021-09-01 15:37   ` Leo Famulari
2021-09-01 16:50     ` Xinglu Chen
2021-09-02 16:51       ` Leo Famulari
2021-09-02 17:29         ` Leo Famulari
2021-09-03 16:11           ` Xinglu Chen
2021-09-03 16:35             ` Leo Famulari
2021-09-03 16:57               ` Leo Famulari
2021-09-03 20:03               ` Xinglu Chen
2021-09-04 21:00                 ` Leo Famulari
2021-09-08 21:15       ` Ludovic Courtès
2021-09-02 17:08 ` Leo Famulari
2021-09-08 21:28 ` Ludovic Courtès
2021-09-08 22:21 ` Jonathan McHugh
2021-09-08 22:38   ` Leo Famulari
  -- strict thread matches above, loose matches on Subject: below --
2021-09-03  5:51 Sarah Morgensen
2021-09-03 21:14 Sarah Morgensen
2021-09-03 22:11 ` Liliana Marie Prikler
2021-09-04 12:32   ` Taylan Kammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27af2d4efec4ced1e8411b1d993dbc8112d26cb7.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=guix-devel@gnu.org \
    --cc=iskarian@mgsn.dev \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).