guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leo Famulari
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Wed, 08 Sep 2021 18:38:27 -0400
User-agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc

I think Ludo meant difftastic:

https://github.com/Wilfred/difftastic

On Wed, Sep 8, 2021, at 18:21, Jonathan McHugh wrote:
> 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
> indieterminacy@libre.brussels
> 
> September 8, 2021 11:31 PM, "Ludovic Courtès" <ludo@gnu.org> wrote:
> 
> > Hello!
> > 
> > Sarah Morgensen <iskarian@mgsn.dev> 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’.
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]