[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Liliana Marie Prikler |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Sat, 04 Sep 2021 00:11:41 +0200 |
User-agent: |
Evolution 3.34.2 |
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
- Re: Can we find a better idiom for unversioned packages?, (continued)
- 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
Re: Can we find a better idiom for unversioned packages?, Sarah Morgensen, 2021/09/03
Re: Can we find a better idiom for unversioned packages?, Sarah Morgensen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?,
Liliana Marie Prikler <=
Re: Can we find a better idiom for unversioned packages?, Ludovic Courtès, 2021/09/08