Hi Ludo, Just checking:
Is Diffstatic a real tool? It wasnt quite clear to me (and I fancy finding a new diff tool). ==================== Jonathan McHugh [email protected] September 8, 2021 11:31 PM, "Ludovic Courtès" <[email protected]> wrote: > Hello! > > Sarah Morgensen <[email protected]> skribis: > >> Currently, there are about 1500 packages defined like this: >> >> (define-public sbcl-feeder >> (let ((commit "b05f517d7729564575cc809e086c262646a94d34") >> (revision "1")) >> (package >> [...]))) >> >> I feel like there are some issues with this idiom (in no particular >> order): > > I’m late to the party but I’ll complement previous answers. :-) > >> 1. When converting between this idiom and regularly versioned packages, >> the git diff shows the whole package changing because of the indentation >> change. > > One can use ‘git diff -w’ to work around that (or the newfangled > Diffstatic tool.) > >> 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. > > Right, these pieces of information are not “first-class”, except in the > ‘git-reference’ record (or similar) for the commit ID. Do you have > examples in mind where it’s insufficient? > > [...] > >> 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. > > I can sympathize with the feeling, but I’m not sure what to do. A > ‘vcs-version’ record as Maxime proposes seems a bit overkill to me (and > it would probably have an impact on performance, build times, and > whatnot.) > >> 6. Not a direct complaint, but I feel like the overall package interface >> was designed before straight-from-vcs unversioned packages were so >> common, and so this idiom developed organically to work around that. > > Sure, though “straight-from-vcs” and “unversioned” are two different > things: I’m fine with the former, but the latter equates to upstream > telling its users “go find a revision that works for you”. I think > releases still make sense for any non-trivial piece of software. > > As noted in the manual (info "(guix) Version Numbers"), packages built > from arbitrary commits were supposed to be exceptional. Perhaps the > reason we’re having this conversation now is that development practices > are evolving towards what looks like chaos. :-) > > Thanks, > Ludo’.
