Re: Can we find a better idiom for unversioned packages?

[Liliana Marie Prikler]

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