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? > > 4. Horizontal space is at a premium, and an extra two spaces here > > and there add up. (Personally, I think we could do with a > > define-public-package macro to save another two spaces, but that's > > for another day...) The worst offenders in horizontal space typically come from the packages themselves and going from 79 to 81 in select outliers is AFAIU acceptable. > > 5. The closest thing we have to a standardized way of generating > > versions for these packages is `(version (git-version "0.0.0" > > revision commit))`. We can do better than that boilerplate. This concerns packages without a public release, many of which never make one in the belief that commit hashes are valid versions (they are not). > Suggestion: extend the 'version' field. More specifically, > introduce a new record <full-version>, like this: > > (define-record-type* <extended-version> extended-version make- > extended-version > extended-version? this-version > ;; something like 1.2.3 (TODO better name) > (base extended-version-base) > (revision extended-version-revision) > (commit extended-version-commit)) > > (define (version->string version) > (match version > ((? string?) version) > (($ <extended-version> ...) code from original git-version and > hg-version))) > > ;; TODO: > ;; adjust git-file-name and hg-file-name to accept <extended-version> > records > ;; (as well as the ‘old style’ for compatibility) > > 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. Perhaps we could make the point that origins can be versioned just like packages can and should think about where the version field really belongs. I think having a per-origin version field and making it so that the package defaults to the origin version unless the package itself has a version specified, might be a better solution philosophically speaking. Technically, it would only solve 1, 4 and 5, but there's a separate workaround for 2 and I don't really think 3 to be that big of an issue. Regards
