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