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

["Jonathan McHugh" <indieterminacy@libre.brussels>]

September 1, 2021 8:35 PM, "Liliana Marie Prikler" <leo.prikler@student.tugraz.at> wrote

> Making our rando commit git versions look like such other distro
> versions does come at a disadvantage though, particularly when we look
> at it through the lense of someone not used to Guix' versioning scheme.
> Instead of telling us "yeah, this is the Nth time we picked a rando
> commit since the last release and this time it's de4db3ef", users
> coming from such distros would assume "oh well, this is still good ol'
> 1.0 with some more patches applied". So while the commit itself does
> not give us any particularly useful information (unless you're that
> person who uses this part of the version string to look the commit up
> on hubbucket), especially not when thinking in the context of
> versioning scheme, it does provide the existential information of "hold
> on, this is not a release commit, it's something else" and might thus
> direct users to be a little more attentive when they'd otherwise go
> "yep, upstream considers this solid and Guix considers it even more
> solid, so it's the solidest". Note, that this can be overcome both by
> teaching/learning about it and by using a special sigil as mentioned
> above.

Perhaps a function revealing metadata based upon the version string would allow more people get an overview without visiting hubbucket^1?

Would that be any weirder and awkward for workflows than the command `guix download'?
=> https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html

Even better, highlighting the part of the string and launching an appropriate context in Emacs-Hyperbole

> My personal answer to this might be a disappointing one, as in that
> case I believe we wouldn't even need procedures like git-version to
> form them, but could instead use <upstream-version>-<guix-revision> as
> a mere convention like many more popular distros already do. If the
> dash is overused for that, we could also use a different symbol, though
> perhaps there's not that many on a typical US keyboard to reserve one
> as a revision delimiter.

# Apologies for being off topic
The inclusion of that character '£' on keyboards bothers me - Ive never seen anybody use it (though maybe I have some fuzzy memory with regards to the Commodore 64).

If it unfortunately is on an international band of keyboard classes consider it as a delimiter. Otherwise Im ripping out that button and never interfacing the number 3 again.

^1 Is that pronounced bouquet? 
=> https://keepingupappearances.fandom.com/wiki/Hyacinth_Bucket


====================
Jonathan McHugh
indieterminacy@libre.brussels


> Am Mittwoch, den 01.09.2021, 18:39 +0200 schrieb Maxime Devos:
> 
>> Liliana Marie Prikler schreef op wo 01-09-2021 om 15:33 [+0200]:
>> Hi
>> 
>> Am Dienstag, den 31.08.2021, 23:20 +0200 schrieb Maxime Devos:
>>> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]:
>>>> Hello Guix,
>>>> 
>>>> Currently, there are about 1500 packages defined like this:
>>>> 
>>>> --8<---------------cut here---------------start------------->8-
>>>> --
>>>> (define-public sbcl-feeder
>>>> (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
>>>> (revision "1"))
>>>> (package
>>>> [...])))
>>>> --8<---------------cut here---------------end--------------->8-
>>>> --
>>>> 
>>>> I feel like there are some issues with this idiom (in no
>>>> particular
>>>> order):
>>>> 
>>>> 1. When converting between this idiom and regularly versioned
>>>> packages, the git diff shows the whole package changing because
>>>> of
>>>> the indentation change.
>> 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.
>> 
>>>> 2. We cannot get at the source location for the definition of
>>>> 'commit' or 'revision'. This would be useful for updating
>>>> these
>>>> packages with `guix refresh -u`. There is a proposed patch [0]
>>>> to
>>>> work around this, but it *is* a workaround.
>> Other versioning idioms would also be workarounds, wouldn't they?
>> 
>>>> 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.
>> What purpose would extracting those serve however?
>> 
>> Not losing the revision is useful for things like
>> <https://issues.guix.gnu.org/50072>, to be able to determine the old
>> revision. (That's not about inheriting packages though.)
> 
> Isn't that addressed by addressing the second point, though? Like, if
> you know the source location of the revision, you can read it back to
> get the value itself (or possibly even access it as-is), no?
> 
>> [...]
>>> To be used like:
>>> 
>>> (define-public sbcl-feeder
>>> (name "sbcl-feeder")
>>> (version (extended-version
>>> (base "1.0.0")
>>> (revision 1)
>>> (commit
>>> "b05f517d7729564575cc809e086c262646a94d34")))
>>> (source
>>> (origin
>>> (method git-fetch)
>>> (uri (git-reference ...)
>>> (url ...)
>>> ;; git-reference needs to be extended to retrieve the
>>> commit from the version
>>> (version version)))
>>> (file-name (git-file-name "feeder" version))
>>> (sha256 ...)))
>>> [...])
>>> 
>>> That should address 1,2,3,4 and 5.
>>> 
>>> One problem with this approach is that most users of 'package-
>>> version' expect it to return a string. Maybe adding a keyword
>>> argument '#:full-version? #t/#f' defaulting to #f would work?
>> I think the bigger problem here is that you're moving bits meant
>> for
>> the origin into the version only to be able to point to the version
>> from the origin. Even accepting that you could use "commit" or a
>> separate field to encode SVN/CVS revision numbers instead of
>> hashes,
>> everything beyond the revision number is basically pointless from a
>> versioning scheme POV and only really useful to fetch the source
>> code.
>> As Xinglu Chen points out, a commit hash encodes remarkably little
>> on its own.
>> 
>> The commit is largely useless, ok. If the (first few characters of)
>> the git commit/svn revision are removed from the version strings, it
>> can be removed from the proposed extended-version.
>> 
>> Otherwise, it would seem you wouldn't mind extended-version if it
>> only had the 'base version' and 'revision' field (in the guix sense,
>> not the SVN sense of revision), or am I misunderstanding here?
> 
> That was not my suggestion, but let's entertain the idea, shall we? In
> that case, we would discard the commit part from the version field,
> which might not be everyone's tea, but I'm more or less indifferent as
> to whether to include the hash there or not – after all, even if it was
> lacking, we'd quickly get it through inspecting the package
> description. If we simply didn't capture the hash at all except inside
> the commit field of the origin, we would gain 1, 4 and 5 so the
> question is whether we should have an extended version so as to update
> the revision more easily...
> 
> My personal answer to this might be a disappointing one, as in that
> case I believe we wouldn't even need procedures like git-version to
> form them, but could instead use <upstream-version>-<guix-revision> as
> a mere convention like many more popular distros already do. If the
> dash is overused for that, we could also use a different symbol, though
> perhaps there's not that many on a typical US keyboard to reserve one
> as a revision delimiter.
> 
> Making our rando commit git versions look like such other distro
> versions does come at a disadvantage though, particularly when we look
> at it through the lense of someone not used to Guix' versioning scheme.
> Instead of telling us "yeah, this is the Nth time we picked a rando
> commit since the last release and this time it's de4db3ef", users
> coming from such distros would assume "oh well, this is still good ol'
> 1.0 with some more patches applied". So while the commit itself does
> not give us any particularly useful information (unless you're that
> person who uses this part of the version string to look the commit up
> on hubbucket), especially not when thinking in the context of
> versioning scheme, it does provide the existential information of "hold
> on, this is not a release commit, it's something else" and might thus
> direct users to be a little more attentive when they'd otherwise go
> "yep, upstream considers this solid and Guix considers it even more
> solid, so it's the solidest". Note, that this can be overcome both by
> teaching/learning about it and by using a special sigil as mentioned
> above.
> 
> All in all, I don't think putting too much "opinion" in the version
> field by storing it as a record is a good idea. It's fine if it's just
> a string that can be parsed/version-compared. We could also make it a
> list like Emacs does and like we use internally, though I'm not too
> certain of what the benefit of that would be at the cost of breaking
> pretty much everything (and probably putting in some opinions as to
> what is to be delimited by dots and what by dashes).
> 
> Regards