Add support for other formats of Guix channels

DoneSubmitted by EuAndreh.
Details
4 participants
  • EuAndreh
  • Leo Famulari
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Severity
normal
E
E
EuAndreh wrote on 15 Sep 19:30 +0200
(address . bug-guix@gnu.org)
163172701717.1270740.9988334410334115700@localhost
As I've described in [0], one can't have a Guix channel served over Git's"Dumb HTTP" protocol. That is caused by libgit's inability to do so [1].
Guix channel authors may want to serve channels:- via "Dumb HTTP" Git repositories;- via other DVCS like Mercurial, Fossil, BitKeeper;- decoupled from the backing versioning tool.
My initial though is that making Guix knowing how to handle channels served astarballs would suffice, and cover all of the above. Those channels wouldn'thave the exact same caching and authentication characteristics as channelsserved via Git repositories, but that seems OK.
WDYT?
[0]: https://yhetil.org/guix-user/162732098483.1190082.2428052336447457010@localhost/t/#m8bb1fc83a8eccd9819085432a59bad9257ef434a[1]: https://github.com/libgit2/libgit2/issues/4652#issuecomment-390903142
L
L
Ludovic Courtès wrote on 16 Sep 10:17 +0200
(name . EuAndreh)(address . eu@euandre.org)(address . 50606@debbugs.gnu.org)
87ee9p2aub.fsf@gnu.org
Hi,
EuAndreh <eu@euandre.org> skribis:
Toggle quote (15 lines)> As I've described in [0], one can't have a Guix channel served over Git's> "Dumb HTTP" protocol. That is caused by libgit's inability to do so [1].>> Guix channel authors may want to serve channels:> - via "Dumb HTTP" Git repositories;> - via other DVCS like Mercurial, Fossil, BitKeeper;> - decoupled from the backing versioning tool.>> My initial though is that making Guix knowing how to handle channels served as> tarballs would suffice, and cover all of the above. Those channels wouldn't> have the exact same caching and authentication characteristics as channels> served via Git repositories, but that seems OK.>> WDYT?
Channel authentication and downgrade prevention are very much linked toGit, though they could work with any append-only kind of DVCS.
Now, the implementation is (purposefully) very much Git-only; the formatof channel specs is somewhat Git-only as well. I understand it can befrustrating users of other VCSes, but from a maintenance viewpoint,supporting a single VCS greatly simplifies things. I also think it’sbeneficial from a user interface standpoint because it allows us toprovide tighter integration than if there was a high-level abstractionlayer.
All in all, I’m not in favor of supporting other version control toolsfor channels.
Supporting the “dump HTTP” Git transport would be nice, but as youwrite, it’s more of a feature request for libgit2.
Thanks,Ludo’.
Z
Z
zimoun wrote on 16 Sep 13:18 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ2sM6is-dp0A8+9M+QN=QJDO35km_MrWHhto8XdCu0NuA@mail.gmail.com
Hi,
On Thu, 16 Sept 2021 at 10:18, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (4 lines)> EuAndreh <eu@euandre.org> skribis:
> > Guix channel authors may want to serve channels:
[...]
Toggle quote (3 lines)> > - via other DVCS like Mercurial, Fossil, BitKeeper;> > - decoupled from the backing versioning tool.
[...]
Toggle quote (3 lines)> All in all, I’m not in favor of supporting other version control tools> for channels.
Adding more all to "all in all". :-)
Support other VCS would mean a lot of work: refactor "pull" and thenbreak several CLIs (pull, time-machine, describe) -- without speakingabout "guix git" subcommand. I do not know if all the Git conceptscurrently used by Guix translate well to other VCS. Moreover thetransparent recent fallback to SWH for channels would also needs pieceof work -- it is not straightforward to fetch back content frommetadata at hand; it is currently only done for Git source and theothers VCS are still WIP, i.e., they do not work out-of-the-box.Well, from a pragmatic point of view, I am not convinced that sucheffort is worth considering the popularity of Git vs other-VCS.
All the best,simon
E
E
EuAndreh wrote on 16 Sep 19:41 +0200
(address . 50606@debbugs.gnu.org)
163181407045.1503137.63518666550594558@localhost
I agree with most points, but I'm not proposing creating integrations with otherDVCS, en par with the current Git integration.
My proposal was a little more crude: get the channel code from a tarball. Inthis model there are no authentications with fingerprint or signed commits,neither "guix pull" would know much about the before/after state of a channelbesides comparing the checksum of the whole tarball.
This lower level abstraction is much less sofisticated, and would probably meanrefetching and rebuilding from tarball-backed channels than Git channels. Butthis also means that the requirement is lower, and much more universal: atarball file served over HTTP, compared to a specific Git HTTP protocol.
E
E
EuAndreh wrote on 16 Sep 19:48 +0200
(address . 50606@debbugs.gnu.org)
163181448971.1503137.13820761374830683288@localhost
In this model, downgrade prevention would a) be inexistant or b) require workfrom the upstream tarball provider, to produce tarballs with metadata files thatcould provide such data.
Authentication could be done by relying on TLS, or requiring a signature file.
E
E
EuAndreh wrote on 16 Sep 19:51 +0200
(address . 50606@debbugs.gnu.org)
163181467227.1503137.16169534887628959834@localhost
I'm very much in favor of keeping the current channel implementation leveragingaspects specific to Git, and I also don't think that adding any other DVCS isworth it.
L
L
Ludovic Courtès wrote on 16 Sep 22:21 +0200
(name . EuAndreh)(address . eu@euandre.org)
878rzwz2y3.fsf@gnu.org
EuAndreh <eu@euandre.org> skribis:
Toggle quote (10 lines)> My proposal was a little more crude: get the channel code from a tarball. In> this model there are no authentications with fingerprint or signed commits,> neither "guix pull" would know much about the before/after state of a channel> besides comparing the checksum of the whole tarball.>> This lower level abstraction is much less sofisticated, and would probably mean> refetching and rebuilding from tarball-backed channels than Git channels. But> this also means that the requirement is lower, and much more universal: a> tarball file served over HTTP, compared to a specific Git HTTP protocol.
Note that we already have -L and GUIX_PACKAGE_PATH as an alternative tofull-blown channels. I’d recommend using that when in need of alightweight alternative. How does that sound?
Thanks,Ludo’.
L
L
Leo Famulari wrote on 17 Sep 01:44 +0200
(name . EuAndreh via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
YUPWw0LWykoOPJ86@jasmine.lan
On Thu, Sep 16, 2021 at 02:41:10PM -0300, EuAndreh via Bug reports for GNU Guix wrote:
Toggle quote (5 lines)> My proposal was a little more crude: get the channel code from a tarball. In> this model there are no authentications with fingerprint or signed commits,> neither "guix pull" would know much about the before/after state of a channel> besides comparing the checksum of the whole tarball.
For this use case, where you don't require many of the `guix pull`features, you could use GUIX_PACKAGE_PATH instead:
https://guix.gnu.org/cookbook/en/html_node/GUIX_005fPACKAGE_005fPATH.html
Z
Z
zimoun wrote on 17 Sep 10:16 +0200
(name . EuAndreh)(address . eu@euandre.org)
CAJ3okZ01Jh5Ot9+qttS_OAx-tMD7muRi-tqEnzzjTUSxRZCe7Q@mail.gmail.com
Hi,
On Thu, 16 Sept 2021 at 19:41, EuAndreh <eu@euandre.org> wrote:
Toggle quote (5 lines)> My proposal was a little more crude: get the channel code from a tarball. In> this model there are no authentications with fingerprint or signed commits,> neither "guix pull" would know much about the before/after state of a channel> besides comparing the checksum of the whole tarball.
Somehow, IIUC your explanations, you would like to be able to set an'origin' as channel source. Something like that:
Toggle snippet (13 lines)(cons* (origin (method url-fetch) (uri "https://example.org/archive.tar.gz") (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))) (channel (name 'extra) (url "https://example.org/extra.git")) %default-channels)
Therefore, it would be possible to have any VCS already supported.
However, it is fixed and update means change at least the checksum tothe channels.scm file.
Well, I do not know if it is more convenient than what Ludo and Leosuggested. :-)

Cheers,simon
E
E
EuAndreh wrote on 17 Sep 12:41 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
163187528655.1642483.16028637497147388402@localhost
This is a reasonable compromise. It is less self-contained than a singlechannel file definition, and requires me or the consumer a bit more upfrontsetup, but I'm OK with that.
E
E
EuAndreh wrote on 17 Sep 12:44 +0200
(name . zimoun)(address . zimon.toutoune@gmail.com)
163187544719.1642483.2726968864829579164@localhost
Having a checksum would at least be more declarative and self-contained, butnot as convenient. A variation of this idea is to not have the checksum, andallow the tarball to be changing over time, like a tarball representing a branchon a repository that gets commits over time.
E
E
EuAndreh wrote on 17 Sep 12:46 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)
163187560586.1673476.8471074501690670822@localhost
Shall we close this bug?
Z
Z
zimoun wrote on 17 Sep 19:00 +0200
(name . EuAndreh)(address . eu@euandre.org)
CAJ3okZ2GXbDBj+EupnP4X-6dbjErjH_=Zau9Tq1HbPJc_OECSA@mail.gmail.com
Hi,
On Fri, 17 Sept 2021 at 12:47, EuAndreh <eu@euandre.org> wrote:
Toggle quote (3 lines)>> Shall we close this bug?
I think this wish,
Guix channel authors may want to serve channels:- via "Dumb HTTP" Git repositories;
still makes sense.
Cheers,simon
L
L
Ludovic Courtès wrote on 18 Sep 12:07 +0200
control message for bug #50606
(address . control@debbugs.gnu.org)
871r5murgu.fsf@gnu.org
tags 50606 wontfixclose 50606quit
L
L
Ludovic Courtès wrote on 18 Sep 12:08 +0200
Re: bug#50606: Add support for other formats of Guix channels
(name . zimoun)(address . zimon.toutoune@gmail.com)
87wnnetcvu.fsf@gnu.org
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
Toggle quote (6 lines)> On Fri, 17 Sept 2021 at 12:47, EuAndreh <eu@euandre.org> wrote:>>>> Shall we close this bug?>> I think this wish,
Done!
Toggle quote (5 lines)> Guix channel authors may want to serve channels:> - via "Dumb HTTP" Git repositories;>> still makes sense.
Yes.
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 50606@debbugs.gnu.org