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 , to be able to determine the old revision. (That's not about inheriting packages though.) > [...] > > 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? Geetings, Maxime.