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
