From: "Ludovic Courtès" <ludo@gnu.org>
To: Sarah Morgensen <iskarian@mgsn.dev>
Cc: guix-devel@gnu.org
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Wed, 08 Sep 2021 23:28:54 +0200 [thread overview]
Message-ID: <8735qezrhl.fsf@gnu.org> (raw)
In-Reply-To: <8635qp1j6k.fsf@mgsn.dev> (Sarah Morgensen's message of "Tue, 31 Aug 2021 12:57:23 -0700")
Hello!
Sarah Morgensen <iskarian@mgsn.dev> skribis:
> Currently, there are about 1500 packages defined like this:
>
> (define-public sbcl-feeder
> (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
> (revision "1"))
> (package
> [...])))
>
> I feel like there are some issues with this idiom (in no particular
> order):
I’m late to the party but I’ll complement previous answers. :-)
> 1. When converting between this idiom and regularly versioned packages,
> the git diff shows the whole package changing because of the indentation
> change.
One can use ‘git diff -w’ to work around that (or the newfangled
Diffstatic tool.)
> 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.
Right, these pieces of information are not “first-class”, except in the
‘git-reference’ record (or similar) for the commit ID. Do you have
examples in mind where it’s insufficient?
[...]
> 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.
I can sympathize with the feeling, but I’m not sure what to do. A
‘vcs-version’ record as Maxime proposes seems a bit overkill to me (and
it would probably have an impact on performance, build times, and
whatnot.)
> 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.
Sure, though “straight-from-vcs” and “unversioned” are two different
things: I’m fine with the former, but the latter equates to upstream
telling its users “go find a revision that works for you”. I think
releases still make sense for any non-trivial piece of software.
As noted in the manual (info "(guix) Version Numbers"), packages built
from arbitrary commits were supposed to be exceptional. Perhaps the
reason we’re having this conversation now is that development practices
are evolving towards what looks like chaos. :-)
Thanks,
Ludo’.
next prev parent reply other threads:[~2021-09-08 21:31 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
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 [this message]
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=8735qezrhl.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=iskarian@mgsn.dev \
/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).