From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mEQiAX4AzV52YgAA0tVLHw (envelope-from ) for ; Tue, 26 May 2020 11:41:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 2Gd4OH0AzV4SRgAAbx9fmQ (envelope-from ) for ; Tue, 26 May 2020 11:41:49 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B13539402A0 for ; Tue, 26 May 2020 11:41:49 +0000 (UTC) Received: from localhost ([::1]:52266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdXxs-0006HR-NO for larch@yhetil.org; Tue, 26 May 2020 07:41:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdXxk-0006HJ-03 for guix-devel@gnu.org; Tue, 26 May 2020 07:41:40 -0400 Received: from mail-qv1-xf43.google.com ([2607:f8b0:4864:20::f43]:35664) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdXxi-0003Md-Jg; Tue, 26 May 2020 07:41:39 -0400 Received: by mail-qv1-xf43.google.com with SMTP id x13so9249953qvr.2; Tue, 26 May 2020 04:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rbtUcGtdhek1CeolS2FDe5J7oAU3BL6FN0ovRiVqOlI=; b=U8kSogVCSCJGq6D8MRPkt9hZQo1iiw5EQzSNtnAMc/E+mXgIzwJt3ajDkgTcaP2iRL dSuzwvgiZB0Sc0kYJgWUwiei9UhFMQ39s3+/3FZ/gEHjsLm2HfEDWOz4R8v/Ky4Qy4xI Bt0+f0mn/ni8xG+sojOnuwQF4awEc77AD8hHbDFJw3fa5NRusymPoO18cs58Vd7fm8tI dah/Tpc2zJelKn3/0HXWctX3yy25YGBlI2AWO0Tow+Aa8+n6wLKiz0kqy3wrOwgqTTZO p7tJp0R02kRaObjXew6fo1C2onnF4CbaQOPb/xJvTQqePx4peqzPlHrA3smSacYyXVfm UREA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rbtUcGtdhek1CeolS2FDe5J7oAU3BL6FN0ovRiVqOlI=; b=KMV+MBbXWQcg7btz/LzjEH19/Ckk5/zyrqr3hLGIPtTwmWFjFg5K4+jnzoXpH7JVDn Kugwh0zltxwqJ4fdWzFlRx6yfaibCv5T28L/L46BaTy6Z/mc5kfJBjxYgI+ej5tuqbUN XnUTLD/39mGHq61lBeWfhznD+Oxd2Mfls+3F+/eiJS72S7Y4gIrqAfL2j60q9mV5SbMk 8Gr3gCeTDc/hu3UEtYH1OnN/HPhQtygU7B4Zj7xDLenqpdkUeFCSc9W60ECB0dmcCQ86 ISzNO0khcUtVUbB4Sb95Sn2PcjBJINNO1CyxJWudlVizkV2Iv7Nrjb1youQeAJ8XBodd tyjg== X-Gm-Message-State: AOAM533tsrgJCDMWcO/bk7hmaILT1xmvNtY5UzlvNq60q3r6xz+ldPUh eHuFWix2MMnM3TKgtChGkGiioVmA9qdTyDtaWKx/sT2J X-Google-Smtp-Source: ABdhPJyU5iEr+bKolZotQZL3DCbNLY+qI2ODdTfjwVROWt+ZSLd7ILISAxbLZ68TkRoin11kD2sc7vgX3KbunQP1T8I= X-Received: by 2002:ad4:5553:: with SMTP id v19mr19025853qvy.77.1590493296718; Tue, 26 May 2020 04:41:36 -0700 (PDT) MIME-Version: 1.0 References: <20200306091524.5044.11103@vcs0.savannah.gnu.org> <20200306091525.E8A1621163@vcs0.savannah.gnu.org> <87o8t9lfci.fsf@devup.no> <871rq5bjzf.fsf@ambrevar.xyz> <87lfodl6u5.fsf@devup.no> <87tv2vgdlg.fsf@gnu.org> <87lfo72b8i.fsf@ambrevar.xyz> In-Reply-To: From: zimoun Date: Tue, 26 May 2020 13:41:25 +0200 Message-ID: Subject: Re: best practise between git-fetch vs url-fetch? To: Guix Devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::f43; envelope-from=zimon.toutoune@gmail.com; helo=mail-qv1-xf43.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marius Bakke , Brice Waegeneire Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=U8kSogVC; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: 1.09 X-TUID: OtK5pYjfSxPE Dear all, On Thu, 14 May 2020 at 18:16, Jack Hill 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 constraint= s > (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 whe= n > 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 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 wrote: > An other argument in recommending the 'git-fetch' method is that it > facilitate the use of =E2=80=9Cguix build --with-commit=E2=80=9D: +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 pack= ages. On Wed, 13 May 2020 at 20:07, Tobias Geerinckx-Rice 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=C2=B9, though, so is --with-source=3D 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=3D/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=3Dbamm=3DXXXXX 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=C3=A8s 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=E2=80=99s kinda happening on leaf packages, often upstream developers = people > don=E2=80=99t bother running =E2=80=9Cmake dist=E2=80=9D. It=E2=80=99ll = 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