Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

Hello Pierre,

guix-commits@gnu.org writes:

> ambrevar pushed a commit to branch master
> in repository guix.
>
> commit 744f445c920f60e9080f42866c802184a1503a80
> Author: Pierre Neidhardt <mail@ambrevar.xyz>
> AuthorDate: Thu Mar 5 10:34:21 2020 +0100
>
>     gnu: fmt: Use HTTPS and git-fetch.
>     
>     * gnu/packages/pretty-print.scm (fmt)[source]: Use git-fetch.
>     [home-page]: Use HTTPS.

Why change to git-fetch here, when upstream provides a zipball?

The unzip input can be removed now, I guess.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Duh, I confused these with the github generated archive, sorry about
that.

Is there any preference between git-fetch and url-fetch?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Duh, I confused these with the github generated archive, sorry about
> that.
>
> Is there any preference between git-fetch and url-fetch?

url-fetch requires less bandwidth, and does not depend on 'git'.

Though the most important distinction is that uploaded releases
sometimes contain pre-processed sources (e.g. documentation) that need
additional dependencies or scripts when building from the raw repository
(this is why you often need to add autoconf, libtool & friends as inputs
when building Autotools projects from git).

I don't know whether there is a difference between the uploaded fmt
zipball and the git repository.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 66 bytes --]

OK, I'll fix it.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 79 bytes --]

Fixed.
Thanks for the catch!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Duh, I confused these with the github generated archive, sorry about
>> that.
>>
>> Is there any preference between git-fetch and url-fetch?
>
> url-fetch requires less bandwidth, and does not depend on 'git'.
>
> Though the most important distinction is that uploaded releases
> sometimes contain pre-processed sources (e.g. documentation) that need
> additional dependencies or scripts when building from the raw repository
> (this is why you often need to add autoconf, libtool & friends as inputs
> when building Autotools projects from git).
>
> I don't know whether there is a difference between the uploaded fmt
> zipball and the git repository.

Other considerations:

  - Bandwidth requirement for source code downloads has never been a
    criterion so far.

  - Git references are nice because they’re (roughly) content-addressed.

  - ‘guix lint -c archival’ archives Git references on Software
    Heritage; it does not archive tarballs (though SWH will do it
    for us eventually.)

Ludo’.

Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Other considerations:
>
>   - Bandwidth requirement for source code downloads has never been a
>     criterion so far.
>
>   - Git references are nice because they’re (roughly) content-addressed.
>
>   - ‘guix lint -c archival’ archives Git references on Software
>     Heritage; it does not archive tarballs (though SWH will do it
>     for us eventually.)

I have already reverse the change... Oops! :p

I guess we need to decide on a best practice then :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

best practise between git-fetch vs url-fetch?

[zimoun]

Dear,

Based on these 2 messages [1,2], what is the consensus between
git-fetch and url-fetch?

Pushing to SWH when linting appears to me winning the pros/cons.  Even
if SWH should eventually fetch http://guix.gnu.org/sources.json soon.
And the other big pros from my point of view is the content-addressed
Git references.

Well, does it make sense to state on a recommended method?


All the best,
simon


[1] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00091.html
On Fri, 6 Mar 2020 at 18:41, Marius Bakke <mbakke@fastmail.com> wrote:

> url-fetch requires less bandwidth, and does not depend on 'git'.
>
> Though the most important distinction is that uploaded releases
> sometimes contain pre-processed sources (e.g. documentation) that need
> additional dependencies or scripts when building from the raw repository
> (this is why you often need to add autoconf, libtool & friends as inputs
> when building Autotools projects from git).
>
> I don't know whether there is a difference between the uploaded fmt
> zipball and the git repository.


[2] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00189.html
On Wed, 11 Mar 2020 at 15:39, Ludovic Courtès <ludo@gnu.org> wrote:

> Other considerations:
>
>   - Bandwidth requirement for source code downloads has never been a
>     criterion so far.
>
>   - Git references are nice because they’re (roughly) content-addressed.
>
>   - ‘guix lint -c archival’ archives Git references on Software
>     Heritage; it does not archive tarballs (though SWH will do it
>     for us eventually.)

Re: best practise between git-fetch vs url-fetch?

[Brice Waegeneire]

Hello,

On 2020-05-13 01:08, zimoun wrote:
> Based on these 2 messages [1,2], what is the consensus between
> git-fetch and url-fetch?

I was hoping that some one bring this up, thanks.

> Pushing to SWH when linting appears to me winning the pros/cons.  Even
> if SWH should eventually fetch http://guix.gnu.org/sources.json soon.
> And the other big pros from my point of view is the content-addressed
> Git references.

Git references being content-addressed is important because it
make it more difficult for a lazy upstream developer to replace a
tarball in place -because it was somehow broken and they didn't
wanted to bump the version number- and broke a package.  Instead
with git, to broke a package in similar way (with a hash mismatch)
that developer would have to do “git push --force” which is much
more frowned upon since it will affect all the users of that git repo.

An other argument in recommending the 'git-fetch' method is that it
facilitate the use of “guix build --with-commit”:
1. You don't need to find out the git-url of the package,
2. Nor finding which dependencies are missing compared to a tarball
    build (often it's autoconf, libtool, & co.),
3. You don't need to manually tweak phases relating to autoconf and
    the like.
All in all recommending 'git-fetch' make “--with-commit” really more
useful.  This feature is one of my favorite from Guix since it make
testing a patch from an upstream developer really easy, eg.:
“guix build picom --with-commit=picom=vNext”.

> Well, does it make sense to state on a recommended method?

It does, it avoid having to discuss it with each new contributor
and avoid noise in patches about changing the source's method based
on each developer preference (I'm personally guilty of that).

> [1] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00091.html
> On Fri, 6 Mar 2020 at 18:41, Marius Bakke <mbakke@fastmail.com> wrote:
> 
>> url-fetch requires less bandwidth, and does not depend on 'git'.
>> 
>> Though the most important distinction is that uploaded releases
>> sometimes contain pre-processed sources (e.g. documentation) that need
>> additional dependencies or scripts when building from the raw 
>> repository
>> (this is why you often need to add autoconf, libtool & friends as 
>> inputs
>> when building Autotools projects from git).
>> 
>> I don't know whether there is a difference between the uploaded fmt
>> zipball and the git repository.
> 
> 
> [2] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00189.html
> On Wed, 11 Mar 2020 at 15:39, Ludovic Courtès <ludo@gnu.org> wrote:
> 
>> Other considerations:
>> 
>>   - Bandwidth requirement for source code downloads has never been a
>>     criterion so far.
>> 
>>   - Git references are nice because they’re (roughly) 
>> content-addressed.
>> 
>>   - ‘guix lint -c archival’ archives Git references on Software
>>     Heritage; it does not archive tarballs (though SWH will do it
>>     for us eventually.)

Cheers,
- Brice

Re: best practise between git-fetch vs url-fetch?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Les Guix,

Brice Waegeneire 写道：
> Git references being content-addressed is important

That's only tautologically true if we limit ourselves to using raw 
commit hashes instead of the more common (because far more 
practical) named tags.  I obviously don't think we should do that.

If we don't, I fail to see how our git-fetches are 
‘content-addressed’ in a way that url-fetches supposedly aren't. 
Git tags are even easier to modify in place than tarballs, not 
harder.

> --with-commit

Yes, this is niice.  ♥

For the sake of argument¹, though, so is --with-source=<actually 
released and supported upstream tarball dot tar>.

Somehow erasing that hard distinction is the real winning move.

Kind regards,

T G-R

[1]: Obligatory <https://xkcd.com/1432>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: best practise between git-fetch vs url-fetch?

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:

>> --with-commit
>
> Yes, this is niice.  ♥
>
> For the sake of argument¹, though, so is --with-source=<actually released and 
> supported upstream tarball dot tar>.
>
> Somehow erasing that hard distinction is the real winning move.
>
> Kind regards,
>
> T G-R
>
> [1]: Obligatory <https://xkcd.com/1432>.

Heh, I'll take the bait. I also really appreciate how easy we make it for 
people to exercise their software freedom and run modified software. How 
best to make that possible and balance it with other usability constraints 
(e.g. mirror:// urls should be more robust) may vary by package, so I 
agree with Leo that some discretion is needed. However, that's not to say 
that I wouldn't appreciate some guidance as to our default preference when 
there is no package-specific reason to prefer one way over the other.

It seems a bigger problem is when the build method for the git repository 
and release tarball are different. In many packages this is because of the 
pre-generated autotools build system in the release tarballs. Should we 
bootstrap the autotools build system even when building from a release 
tarball? As I understand it, autotools has historically been treated this 
way in part to allow building on systems without the right version of 
autotools, but is that really a problem in Guix? Why should it be treated 
differently than other pre-generated artifacts which we rebuild?

Another improvement we could make here is improving the message about 
Software Heritage in guix lint. Most of the other messages it emits are 
things that the author of a package should consider improving. If the 
Software Heritage message is less actionable, let's make that clearer so 
that people don't think there is a problem with their package definition.

Best,
Jack

Re: best practise between git-fetch vs url-fetch?

[Josh Marshall]

Hello all,

Continuing my Sunday catch-up, I'd like to kick the tires on this.

Tarballs seem to have the following:
+ Faster to build
+ Faster first time download
- Larger downloads for smaller changes
- Autotools are pre-built, negating bootstrapping
- SWH not yet supported (https://forge.softwareheritage.org/T1352)
+ Fewer package dependencies\
+ Can use alternative source versions via `--with-source` -- more
likely for each to work, but fewer options

Git seems to have the following:
- Slower to build
- Slower first time download
+ Smaller incremental downloads
+ More complete bootstrapping
+ SWH support is working
- Adds extra dependency on git
+ Easy use of alternative commits via `--with-commit`

Practically, these options are highly similar, with git having some
edge when it comes to bootstrapping the software more completely, and
avoiding using as many non-source executable things.  But that is
extendable to tarballs as well.

What it comes down for me is that git offers a more coherent history
of a piece of software all in one location.  Tarballs are snapshots in
a software's history, and I'd prefer to just have the entire history
already in one managed and organized location.  That is one things
tarballs can't practically accomplish.

I am also for having a de-factco, soft suggestion that packages use.
I think git-fetch is ever so slightly the better option, and so should
be a "default" recommendation over url-fetch.  That being said, I am
more in favor of having a default than what that default is.

On Thu, May 14, 2020 at 12:16 PM Jack Hill <jackhill@jackhill.us> wrote:
>
> On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:
>
> >> --with-commit
> >
> > Yes, this is niice.  ♥
> >
> > For the sake of argument¹, though, so is --with-source=<actually released and
> > supported upstream tarball dot tar>.
> >
> > Somehow erasing that hard distinction is the real winning move.
> >
> > Kind regards,
> >
> > T G-R
> >
> > [1]: Obligatory <https://xkcd.com/1432>.
>
> Heh, I'll take the bait. I also really appreciate how easy we make it for
> people to exercise their software freedom and run modified software. How
> best to make that possible and balance it with other usability constraints
> (e.g. mirror:// urls should be more robust) may vary by package, so I
> agree with Leo that some discretion is needed. However, that's not to say
> that I wouldn't appreciate some guidance as to our default preference when
> there is no package-specific reason to prefer one way over the other.
>
> It seems a bigger problem is when the build method for the git repository
> and release tarball are different. In many packages this is because of the
> pre-generated autotools build system in the release tarballs. Should we
> bootstrap the autotools build system even when building from a release
> tarball? As I understand it, autotools has historically been treated this
> way in part to allow building on systems without the right version of
> autotools, but is that really a problem in Guix? Why should it be treated
> differently than other pre-generated artifacts which we rebuild?
>
> Another improvement we could make here is improving the message about
> Software Heritage in guix lint. Most of the other messages it emits are
> things that the author of a package should consider improving. If the
> Software Heritage message is less actionable, let's make that clearer so
> that people don't think there is a problem with their package definition.
>
> Best,
> Jack

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Jack Hill <jackhill@jackhill.us> skribis:

> It seems a bigger problem is when the build method for the git
> repository and release tarball are different. In many packages this is
> because of the pre-generated autotools build system in the release
> tarballs. Should we bootstrap the autotools build system even when
> building from a release tarball? As I understand it, autotools has
> historically been treated this way in part to allow building on
> systems without the right version of autotools, but is that really a
> problem in Guix? Why should it be treated differently than other
> pre-generated artifacts which we rebuild?

You’re pointing out a contradiction here.  On one hand, we take
advantage that Autotools-based programs require nothing but a POSIX
shell and make to be built, unlike most other build systems, which
greatly simplifies our dependency tree.  On the other hand, we’re
striving to build everything from source, and Autotools-generated files
look like elephants in this room.  Debian has been dismissing those
files for a long time.

Probably we should aim towards not using pre-built Autotools generated
files and, by extension, probably not using pre-built tarballs when VCS
checkouts are available.

It’s kinda happening on leaf packages, often upstream developers people
don’t bother running “make dist”.  It’ll take some time before tarballs
disappear and needs some thought in particular from a bootstrapping
standpoint.

> Another improvement we could make here is improving the message about
> Software Heritage in guix lint. Most of the other messages it emits
> are things that the author of a package should consider improving. If
> the Software Heritage message is less actionable, let's make that
> clearer so that people don't think there is a problem with their
> package definition.

What message would you suggest?

Thanks,
Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On Sun, 24 May 2020, Ludovic Courtès wrote:

[…]

>> Another improvement we could make here is improving the message about
>> Software Heritage in guix lint. Most of the other messages it emits
>> are things that the author of a package should consider improving. If
>> the Software Heritage message is less actionable, let's make that
>> clearer so that people don't think there is a problem with their
>> package definition.
>
> What message would you suggest?

How about expanding section 7.7 "Invoking Guix Lint" in the manual to 
include a paragraph of advice in the explanation for each checker. For 
example, the advice could be could be "change the source to use git-fetch" 
for "source-unstable-tarball", "exercise judgment on the long-term 
availability of software sources. We think that code hosted on the GNU ftp 
servers will be around for a long time, but code on people's personal 
websites may not be. The greater the risk of the software disappearing, 
the more important is is to use git-fetch in sources so we can trigger 
archiving at Software Heritage" for "archival", and "double check whether 
these inputs really should be native [link to appropriate section of the 
manual]. If they really need to be, leave a comment in the code briefly 
explaining why to help future contributors" for "inputs-should-be-native".

Obviously, those aren't fit to be included in the manual as is, but 
hopefully they give a good idea of what I was thinking. guix lint could 
remind people to check the manual for advice when it detects lint.

That said, I am open to other options, including that this isn't a problem 
that we need to solve.

Best,
Jack

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Jack Hill <jackhill@jackhill.us> skribis:

> On Sun, 24 May 2020, Ludovic Courtès wrote:
>
> […]
>
>>> Another improvement we could make here is improving the message about
>>> Software Heritage in guix lint. Most of the other messages it emits
>>> are things that the author of a package should consider improving. If
>>> the Software Heritage message is less actionable, let's make that
>>> clearer so that people don't think there is a problem with their
>>> package definition.
>>
>> What message would you suggest?
>
> How about expanding section 7.7 "Invoking Guix Lint" in the manual to
> include a paragraph of advice in the explanation for each checker. For
> example, the advice could be could be "change the source to use
> git-fetch" for "source-unstable-tarball", "exercise judgment on the
> long-term availability of software sources. We think that code hosted
> on the GNU ftp servers will be around for a long time, but code on
> people's personal websites may not be. The greater the risk of the
> software disappearing, the more important is is to use git-fetch in
> sources so we can trigger archiving at Software Heritage" for
> "archival", and "double check whether these inputs really should be
> native [link to appropriate section of the manual]. If they really
> need to be, leave a comment in the code briefly explaining why to help
> future contributors" for "inputs-should-be-native".

Regarding the ‘archival’ checker, the manual explains what’s at stake
and what it does:

  https://guix.gnu.org/manual/en/html_node/Invoking-guix-lint.html

I feel like there’s little room for improvement here.

Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Jack Hill]

On May 25, 2020 5:17:02 PM EDT, "Ludovic Courtès" <ludo@gnu.org> wrote:
>Hi,
>
>Jack Hill <jackhill@jackhill.us> skribis:
>
>> On Sun, 24 May 2020, Ludovic Courtès wrote:
>>
>> […]
>>
>>>> Another improvement we could make here is improving the message
>about
>>>> Software Heritage in guix lint. Most of the other messages it emits
>>>> are things that the author of a package should consider improving.
>If
>>>> the Software Heritage message is less actionable, let's make that
>>>> clearer so that people don't think there is a problem with their
>>>> package definition.
>>>
>>> What message would you suggest?
>>
>> How about expanding section 7.7 "Invoking Guix Lint" in the manual to
>> include a paragraph of advice in the explanation for each checker.
>For
>> example, the advice could be could be "change the source to use
>> git-fetch" for "source-unstable-tarball", "exercise judgment on the
>> long-term availability of software sources. We think that code hosted
>> on the GNU ftp servers will be around for a long time, but code on
>> people's personal websites may not be. The greater the risk of the
>> software disappearing, the more important is is to use git-fetch in
>> sources so we can trigger archiving at Software Heritage" for
>> "archival", and "double check whether these inputs really should be
>> native [link to appropriate section of the manual]. If they really
>> need to be, leave a comment in the code briefly explaining why to
>help
>> future contributors" for "inputs-should-be-native".
>
>Regarding the ‘archival’ checker, the manual explains what’s at stake
>and what it does:
>
>  https://guix.gnu.org/manual/en/html_node/Invoking-guix-lint.html
>
>I feel like there’s little room for improvement here.

I think you're right. We have made it this far without too much confusion, and I agree that the text in that section is good. Let's leave it alone.

Best,
Jack

Re: best practise between git-fetch vs url-fetch?

[Leo Famulari]

On Wed, May 13, 2020 at 03:08:26AM +0200, zimoun wrote:
> Based on these 2 messages [1,2], what is the consensus between
> git-fetch and url-fetch?

Do we need a consensus? Sometimes it's enough for the reviewer to 1)
bite their tongue or 2) fix before pushing. Often it's a matter of taste
and it is beneficial to not second-guess the patch author too much, to
not hurt their confidence.

I think we should try to avoid a situation where we have to bootstrap
Git. We do have git-minimal, which works for now. Libgit2 recently
started releasing tarballs, so that could be an option, too.

Another point for url-fetch is that Git's transition from SHA1 to SHA256
identifiers may be easy for us, or it may not be. We don't know yet.

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> I think we should try to avoid a situation where we have to bootstrap
> Git. We do have git-minimal, which works for now. Libgit2 recently
> started releasing tarballs, so that could be an option, too.

Good point.  We could work around that by adding a derivation “built-in
builder” for Git clones, just like we have “builtin:download”.

> Another point for url-fetch is that Git's transition from SHA1 to SHA256
> identifiers may be easy for us, or it may not be. We don't know yet.

I’m “curious” about that transition…

Ludo’.

Re: best practise between git-fetch vs url-fetch?

[zimoun]

Dear all,

On Thu, 14 May 2020 at 18:16, Jack Hill <jackhill@jackhill.us> wrote:

> Heh, I'll take the bait. I also really appreciate how easy we make it for
> people to exercise their software freedom and run modified software. How
> best to make that possible and balance it with other usability constraints
> (e.g. mirror:// urls should be more robust) may vary by package, so I
> agree with Leo that some discretion is needed. However, that's not to say
> that I wouldn't appreciate some guidance as to our default preference when
> there is no package-specific reason to prefer one way over the other.

I second these words. :-)


On Wed, 13 May 2020 at 19:13, Leo Famulari <leo@famulari.name> wrote:

> Do we need a consensus? Sometimes it's enough for the reviewer to 1)
> bite their tongue or 2) fix before pushing. Often it's a matter of taste
> and it is beneficial to not second-guess the patch author too much, to
> not hurt their confidence.

From my point of view, it should not be a matter of taste.  To me, it
should ideally be uniform per file.  For example, bioconductor.scm
uses mainly 'url-fetch' and emacs-xyz.scm mainly 'git-fetch'.
However, some are mixed which does no appear to me right; for example
bioinformatics.scm.

--8<---------------cut here---------------start------------->8---
for f in $(ls -1 gnu/packages/*.scm);
do
    echo $f
    grep "\-fetch" $f \
        | sed -e 's/^[[:space:]]*//' \
        | sort | uniq -c | sort -n
    echo ""
done | less
--8<---------------cut here---------------end--------------->8---


> I think we should try to avoid a situation where we have to bootstrap
> Git. We do have git-minimal, which works for now. Libgit2 recently
> started releasing tarballs, so that could be an option, too.

But, is Git bootstrapped anyway?  Somehow, Guix bootstraps Git, isn't it?
Your point is remove 'git' to the implicit dependency graph, right?


> Another point for url-fetch is that Git's transition from SHA1 to SHA256
> identifiers may be easy for us, or it may not be. We don't know yet.

Tempus narrabo. :-)


On Wed, 13 May 2020 at 10:24, Brice Waegeneire <brice@waegenei.re> wrote:

> An other argument in recommending the 'git-fetch' method is that it
> facilitate the use of “guix build --with-commit”:

+1 for some packages! :-)
-1 for some other ones; for example the ones coming from big
collection as BioConductor released like a whole.


> It does, it avoid having to discuss it with each new contributor
> and avoid noise in patches about changing the source's method based
> on each developer preference (I'm personally guilty of that).

Especially when there is no committer attached to some specific set of packages.


On Wed, 13 May 2020 at 20:07, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> That's only tautologically true if we limit ourselves to using raw
> commit hashes instead of the more common (because far more
> practical) named tags.  I obviously don't think we should do that.

Why?  If there is a good motivation.
We could imagine a transition: recommanding and encouraging
'git-fetch' with raw commit for any addition/update.
However, it is not clear that there is a strong value for such transition. :-)


> For the sake of argument¹, though, so is --with-source=<actually
> released and supported upstream tarball dot tar>.

Well, in my workflow I never used '--with-source' because there is an
extra step that '--with-commit' does not have.  But it is a minor
detail.  The real issue is what Jack described with the autotools (or
any other pre-built X generated files).

For a concrete example, let consider 'htop':

--8<---------------cut here---------------start------------->8---
git clone https://github.com/hishamhm/htop /tmp/htop
git -C /tmp/htop checkout 2.2.0
guix build htop --with-source=/tmp/htop
[...]
running './autogen.sh'
patch-shebang: ./autogen.sh: changing `/bin/sh' to
`/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh'
./autogen.sh: line 3: autoreconf: command not found
--8<---------------cut here---------------end--------------->8---

In my scientific workflow, I find easier to do, e.g.,

    guix build bamm --with-commit=bamm=XXXXX

to test new features or reproduce something based on a paper using one
specific commit.  Well, it is easier to hack on some packages and it
saves time by collectively maintain the burden.


What annoys me is that I cannot predict* for which package it works.
That's why a recommendation per file seems right to me.

*obviously, we could add the method of origin in "guix show"; even it
would help, it is not really the point, IMHO.


> Somehow erasing that hard distinction is the real winning move.

To me, today 'git-fetch' provides more flexibility / hackability than
'url-fetch'.


On Sun, 24 May 2020 at 22:30, Ludovic Courtès <ludo@gnu.org> wrote:

> Probably we should aim towards not using pre-built Autotools generated
> files and, by extension, probably not using pre-built tarballs when VCS
> checkouts are available.

This would help to reduce the "hard distinction".  Well, what could be
a working plan?


> It’s kinda happening on leaf packages, often upstream developers people
> don’t bother running “make dist”.  It’ll take some time before tarballs
> disappear and needs some thought in particular from a bootstrapping
> standpoint.

Well, from a reproducibility point of view, we should not use the
pre-built Autotools generated files, IMHO.



All the best,
simon