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

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 McHug

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

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" wrote: > Hello! > > Sarah Morgensen skribis: > >> Currently

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

Hello! Sarah Morgensen 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 idi

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

Hi, Xinglu Chen skribis: > Well, seeing > > foo-1.0.0-1.2021-01-31 > > gives a user more useful information than something like > > foo-1.0.0-1.cabba9e > > With the former, I can quickly see that the version is from 2021-01-31, > whereas with the latter, I would have to either find the VCS r

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

On Fri, Sep 03, 2021 at 10:03:47PM +0200, Xinglu Chen wrote: > ‘guix describe’ would show the commit of the guix.git repo used, > wouldn’t it? It shows the commit of currently effective revision of Guix, but it can't tell you what revision of Guix a built package came from. > If the date is not p

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

On 04.09.2021 00:11, Liliana Marie Prikler wrote: > > Well, let #f or *unspecified* would also solve the git blame issue, [...] > Only partially on-topic but: I believe *unspecified* should not be used explicitly in code. It's an implementation detail, and by avoiding it in user code, we lessen

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

Hi Sarah, Am Freitag, den 03.09.2021, 14:14 -0700 schrieb Sarah Morgensen: > [...] > > > 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

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

Liliana, Thanks for the criticism! Liliana Marie Prikler writes: > 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: >> > >>

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

On Fri, Sep 03 2021, Leo Famulari wrote: > On Fri, Sep 03, 2021 at 06:11:46PM +0200, Xinglu Chen wrote: >> The date does give an idea of how old the version is, compare that to a >> random string of 7 characters. If a user wants to know the exact >> commit, they can always just run ‘guix edit PAC

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

On Fri, Sep 03, 2021 at 12:35:21PM -0400, Leo Famulari wrote: > 1) To know how old the package's source code is Oh, some more thoughts: What about extending `guix refresh` to help with your use case, assuming that it doesn't already? And what about packages that aren't based on VCS, but on tarba

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

On Fri, Sep 03, 2021 at 06:11:46PM +0200, Xinglu Chen wrote: > The date does give an idea of how old the version is, compare that to a > random string of 7 characters. If a user wants to know the exact > commit, they can always just run ‘guix edit PACKAGE’ and check the > ‘commit’ field in the sou

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

On Thu, Sep 02 2021, Leo Famulari wrote: > On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote: >> On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: >> > > Commit dates don't have a consistent meaning: are they the time of >> > > first revision of a commit? Final revision of a

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

Hi Maxime, Maxime Devos writes: >> > Not losing the revision is useful for things like >> > ;, 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? Lik

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

On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote: > On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: > > > Commit dates don't have a consistent meaning: are they the time of > > > first revision of a commit? Final revision of a commit? Time of > > > signing? Pushing? They ar

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

On Tue, Aug 31, 2021 at 12:57:23PM -0700, Sarah Morgensen wrote: > I do not have a specific solution in mind, but I think there must be > one. I do have a few half-baked ideas, but I'm curious what we can all > come up with together. Or maybe you'll just tell me I'm just being > awfully picky :)

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

On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote: > With the former, I can quickly see that the version is from 2021-01-31, > whereas with the latter, I would have to either find the VCS repo online > or go to my local checkout of it and browse the logs. > > > Commit dates don't have a

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

Liliana Marie Prikler schreef op do 02-09-2021 om 16:20 [+0200]: > Am Donnerstag, den 02.09.2021, 16:09 +0200 schrieb Maxime Devos: > > > > > > > 2. We cannot get at the source location for the definition > > > > > > > of > > > > > > > 'commit' or 'revision'. This would be useful for updating > >

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

Am Donnerstag, den 02.09.2021, 16:09 +0200 schrieb Maxime Devos: > > > > > > 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 pr

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

> > > > > 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. >

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

Liliana Marie Prikler schreef op wo 01-09-2021 om 23:47 [+0200]: > > https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html > Imo the only thing awkard about guix download is that it only handles > tarballs when a large chunk of packages use some sort of version > control. We might w

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

Am Donnerstag, den 02.09.2021, 07:53 + schrieb Jonathan McHugh: > Hi Liliana, > > Given your examples I expect improving upstream CHANGELOG (or third > party) files would be too much of a burden in order to solve the > aforementioned problems. ChangeLogs are generally not installed as part of

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

Hi Liliana, Given your examples I expect improving upstream CHANGELOG (or third party) files would be too much of a burden in order to solve the aforementioned problems. Jonathan September 1, 2021 11:47 PM, "Liliana Marie Prikler" wrote: > Am Mittwoch, den 01.09.2021, 19:48 + schrieb J

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

Am Mittwoch, den 01.09.2021, 19:48 + schrieb Jonathan McHugh: > September 1, 2021 8:35 PM, "Liliana Marie Prikler" < > leo.prik...@student.tugraz.at> wrote > > > Making our rando commit git versions look like such other distro > > versions does come at a disadvantage though, particularly when

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

September 1, 2021 8:35 PM, "Liliana Marie Prikler" wrote > 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 "

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

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, > > >

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

On Wed, Sep 01 2021, Leo Famulari wrote: > On Wed, Sep 1, 2021, at 06:55, Xinglu Chen wrote: >> I never felt like including the commit id in the version of a package >> was useful; e.g., just seeing the first seven characters of the commit >> id doesn’t really tell me anything about the version.

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

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: > > >

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

> > (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-ref

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

On Wed, Sep 1, 2021, at 06:55, Xinglu Chen wrote: > I never felt like including the commit id in the version of a package > was useful; e.g., just seeing the first seven characters of the commit > id doesn’t really tell me anything about the version. I think it is > more useful to put the date of

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

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

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

On Tue, Aug 31 2021, Maxime Devos wrote: > 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 (

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

On Tue, Aug 31 2021, Sarah Morgensen wrote: > Hello Guix, > > Currently, there are about 1500 packages defined like this: > > --8<---cut here---start->8--- > (define-public sbcl-feeder > (let ((commit "b05f517d7729564575cc809e086c262646a94d34") > (revi

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

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")

Can we find a better idiom for unversioned packages?

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<---c