From: Liliana Marie Prikler <leo.prikler@student.tugraz.at>
To: Sarah Morgensen <iskarian@mgsn.dev>
Cc: guix-devel@gnu.org, Xinglu Chen <public@yoctocell.xyz>
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Sat, 04 Sep 2021 00:11:41 +0200 [thread overview]
Message-ID: <a02776967a9850fc276d5ffc1da3708929e1a075.camel@student.tugraz.at> (raw)
In-Reply-To: <86o899xsyr.fsf@mgsn.dev>
Hi Sarah,
Am Freitag, den 03.09.2021, 14:14 -0700 schrieb Sarah Morgensen:
> [...]
>
> > 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.
>
> To be clear, this point was regarding "git blame", not any
> programmatic manipulation.
Well, let #f or *unspecified* would also solve the git blame issue, but
again I don't think the recursive git blame implemented e.g. by magit
is broken too easily by those transitions. I might be wrong about
that, though.
> [...]
> You're largely correct, in that all these reasons are minor. I feel
> that they do add up, though... and, IMO, the current usage of 'let'
> just feels inelegant.
The point is not so much to say "no" because all those points are
minor, but rather to establish which properties a "solution" would
require and which ones are simply nice to have. For example, we need
to be able to update the expression in-place, but referencing its value
for the sake of inheritance is not that important.
> [...]
>
> A minor downside of this method is that developers may have to look
> at the source field to determine the package version if it's not
> directly specified in the package (programmatic access would still
> work). Similarly, anything which parses the raw sexps (such as
> committer.scm) would have to be modified to accommodate.
Point taken.
> Some ideas....
>
> 1. Version-first
>
> (origin
> (version (vcs-version (base "2.13.3")))
> ;; or: (version "2.13.3")
> ;; (would require special-casing, but url-fetch uris would not need
> to
> ;; be modified)
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/git-lfs/git-lfs")
> (commit (string-append "v" version))))
> ;; or: (commit (version->tag version #:prefix "v"))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg")))
>
> Or, if we encode the information a la #50359 [0], but in 'vcs-
> version':
>
> (origin
> (version (vcs-version
> (base "2.13.3")
> (tag-prefix "v")))
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/git-lfs/git-lfs")
> (commit (vcs-version->git-commit version))))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg")))
>
> In some ways it makes more sense to put e.g. tag-prefix in vcs-
> version, rather than package properties, because the transformation
> can occasionally vary between versions.
I don't agree with your assessment. tag-prefix is not a raw string, it
can be a regexp, so if upstream jumps from "v1.2.3" to "release-1.2.4",
you can encode that in one regexp. You can't do that with version
records.
> (origin
> (method git-fetch)
> (version (vcs-version
> (base "0.12.9")
> (identifier "e41b504dca90a25e9be27f296da7ce22e5782893")
> (revision "1")))
> (uri (git-reference
> (url "https://github.com/nosarthur/gita")
> (commit (vcs-version->git-commit version))))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "1k03zgcbhl91cgyh4k7ywyjp00y63q4bqbimncqh5b3lni8l8j5l")))
>
> Another advantage to this approach is that a potential git updater
> only
> has to change the 'version' record.
>
> 2. Reference-first
>
> (define* (git-ref->version ref #:optional base (revision "0")
> #:key prefix suffix)
> (if base
> (vcs-version
> (base base)
> (identifier (git-reference-commit ref))
> (revision revision))
> (let ((prefix-len (or (and=> prefix string-length) 0))
> (suffix-len (or (and=> suffix string-length) 0)))
> (vcs-version
> (base (string-drop (string-drop-right ref suffix-len) prefix-
> len))
> (tag-prefix prefix)
> (tag-suffix suffix)))))
>
> (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/git-lfs/git-lfs")
> (commit "v2.13.3")))
> (version (git-ref->version uri #:prefix "v"))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg")))
>
> (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/nosarthur/gita")
> (commit "e41b504dca90a25e9be27f296da7ce22e5782893")))
> (version (git-ref->version uri "0.12.9" "1"))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "1k03zgcbhl91cgyh4k7ywyjp00y63q4bqbimncqh5b3lni8l8j5l")))
>
> Hmmm. I think this method falls short of the previous because we're
> forced to work backwards from the tag, and it splits the information
> relevant for updating between 'version' and 'uri'.
You know, that you could alternate between version-first for tagged
commits and reference-first for untagged ones, assuming you don't do
the reasonable thing of wrapping the origin in a let&.
Then you'd have
(origin
(method git-fetch)
(version "2.13.3")
(uri (git-reference
(url "https://github.com/git-lfs/git-lfs")
(commit (string-append "v" version))
[...])
and
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/git-lfs/git-lfs")
(commit "e41b504dca90a25e9be27f296da7ce22e5782893")
(version (git-version "0.12.9" (git-reference-commit uri)))
[...])
Of course, you could do something similar with packages as is, but
(git-reference-commit (origin-uri origin)) might be a bit much.
Regards
next prev parent reply other threads:[~2021-09-03 22:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 21:14 Can we find a better idiom for unversioned packages? Sarah Morgensen
2021-09-03 22:11 ` Liliana Marie Prikler [this message]
2021-09-04 12:32 ` Taylan Kammer
-- strict thread matches above, loose matches on Subject: below --
2021-09-03 5:51 Sarah Morgensen
2021-08-31 19:57 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
2021-09-08 22:21 ` Jonathan McHugh
2021-09-08 22:38 ` Leo Famulari
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=a02776967a9850fc276d5ffc1da3708929e1a075.camel@student.tugraz.at \
--to=leo.prikler@student.tugraz.at \
--cc=guix-devel@gnu.org \
--cc=iskarian@mgsn.dev \
--cc=public@yoctocell.xyz \
/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).