all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / Atom feed
* bug#50606: Add support for other formats of Guix channels
@ 2021-09-15 17:30 EuAndreh via Bug reports for GNU Guix
  2021-09-16  8:17 ` Ludovic Courtès
  0 siblings, 1 reply; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-15 17:30 UTC (permalink / raw)
  To: 50606

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?

[0]: https://yhetil.org/guix-user/162732098483.1190082.2428052336447457010@localhost/t/#m8bb1fc83a8eccd9819085432a59bad9257ef434a
[1]: https://github.com/libgit2/libgit2/issues/4652#issuecomment-390903142




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-15 17:30 bug#50606: Add support for other formats of Guix channels EuAndreh via Bug reports for GNU Guix
@ 2021-09-16  8:17 ` Ludovic Courtès
  2021-09-16 11:18   ` zimoun
  0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2021-09-16  8:17 UTC (permalink / raw)
  To: EuAndreh; +Cc: 50606

Hi,

EuAndreh <eu@euandre.org> skribis:

> 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 to
Git, though they could work with any append-only kind of DVCS.

Now, the implementation is (purposefully) very much Git-only; the format
of channel specs is somewhat Git-only as well.  I understand it can be
frustrating users of other VCSes, but from a maintenance viewpoint,
supporting a single VCS greatly simplifies things.  I also think it’s
beneficial from a user interface standpoint because it allows us to
provide tighter integration than if there was a high-level abstraction
layer.

All in all, I’m not in favor of supporting other version control tools
for channels.

Supporting the “dump HTTP” Git transport would be nice, but as you
write, it’s more of a feature request for libgit2.

Thanks,
Ludo’.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16  8:17 ` Ludovic Courtès
@ 2021-09-16 11:18   ` zimoun
  2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
  0 siblings, 1 reply; 14+ messages in thread
From: zimoun @ 2021-09-16 11:18 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: EuAndreh, 50606

Hi,

On Thu, 16 Sept 2021 at 10:18, Ludovic Courtès <ludo@gnu.org> wrote:
> EuAndreh <eu@euandre.org> skribis:

> > Guix channel authors may want to serve channels:

[...]

> > - via other DVCS like Mercurial, Fossil, BitKeeper;
> > - decoupled from the backing versioning tool.

[...]

> 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 then
break several CLIs (pull, time-machine, describe) -- without speaking
about "guix git" subcommand.  I do not know if all the Git concepts
currently used by Guix translate well to other VCS.  Moreover the
transparent recent fallback to SWH for channels would also needs piece
of work -- it is not straightforward to fetch back content from
metadata at hand; it is currently only done for Git source and the
others 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 such
effort is worth considering the popularity of Git vs other-VCS.

All the best,
simon




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 11:18   ` zimoun
@ 2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
                         ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-16 17:41 UTC (permalink / raw)
  To: Ludovic Courtès, zimoun; +Cc: 50606

I agree with most points, but I'm not proposing creating integrations with other
DVCS, en par with the current Git integration.

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.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
@ 2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 17:51         ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 20:21       ` Ludovic Courtès
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-16 17:48 UTC (permalink / raw)
  To: Ludovic Courtès, zimoun; +Cc: 50606

In this model, downgrade prevention would a) be inexistant or b) require work
from the upstream tarball provider, to produce tarballs with metadata files that
could provide such data.

Authentication could be done by relying on TLS, or requiring a signature file.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
@ 2021-09-16 17:51         ` EuAndreh via Bug reports for GNU Guix
  0 siblings, 0 replies; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-16 17:51 UTC (permalink / raw)
  To: Ludovic Courtès, zimoun; +Cc: 50606

I'm very much in favor of keeping the current channel implementation leveraging
aspects specific to Git, and I also don't think that adding any other DVCS is
worth it.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
@ 2021-09-16 20:21       ` Ludovic Courtès
  2021-09-17 10:41         ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 23:44       ` Leo Famulari
  2021-09-17  8:16       ` zimoun
  3 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2021-09-16 20:21 UTC (permalink / raw)
  To: EuAndreh; +Cc: 50606

EuAndreh <eu@euandre.org> skribis:

> 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 to
full-blown channels.  I’d recommend using that when in need of a
lightweight alternative.  How does that sound?

Thanks,
Ludo’.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
  2021-09-16 20:21       ` Ludovic Courtès
@ 2021-09-16 23:44       ` Leo Famulari
  2021-09-17  8:16       ` zimoun
  3 siblings, 0 replies; 14+ messages in thread
From: Leo Famulari @ 2021-09-16 23:44 UTC (permalink / raw)
  To: 50606

On Thu, Sep 16, 2021 at 02:41:10PM -0300, EuAndreh via Bug reports for GNU Guix wrote:
> 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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
                         ` (2 preceding siblings ...)
  2021-09-16 23:44       ` Leo Famulari
@ 2021-09-17  8:16       ` zimoun
  2021-09-17 10:44         ` EuAndreh via Bug reports for GNU Guix
  3 siblings, 1 reply; 14+ messages in thread
From: zimoun @ 2021-09-17  8:16 UTC (permalink / raw)
  To: EuAndreh; +Cc: 50606

Hi,

On Thu, 16 Sept 2021 at 19:41, EuAndreh <eu@euandre.org> wrote:

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

--8<---------------cut here---------------start------------->8---
(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)
--8<---------------cut here---------------end--------------->8---

Therefore, it would be possible to have any VCS already supported.

However, it is fixed and update means change at least the checksum to
the channels.scm file.

Well, I do not know if it is more convenient than what Ludo and Leo
suggested. :-)


Cheers,
simon




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-16 20:21       ` Ludovic Courtès
@ 2021-09-17 10:41         ` EuAndreh via Bug reports for GNU Guix
  2021-09-17 10:46           ` EuAndreh via Bug reports for GNU Guix
  0 siblings, 1 reply; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-17 10:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 50606, zimoun

This is a reasonable compromise.  It is less self-contained than a single
channel file definition, and requires me or the consumer a bit more upfront
setup, but I'm OK with that.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-17  8:16       ` zimoun
@ 2021-09-17 10:44         ` EuAndreh via Bug reports for GNU Guix
  0 siblings, 0 replies; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-17 10:44 UTC (permalink / raw)
  To: zimoun; +Cc: Ludovic Courtès, 50606

Having a checksum would at least be more declarative and self-contained, but
not as convenient.  A variation of this idea is to not have the checksum, and
allow the tarball to be changing over time, like a tarball representing a branch
on a repository that gets commits over time.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-17 10:41         ` EuAndreh via Bug reports for GNU Guix
@ 2021-09-17 10:46           ` EuAndreh via Bug reports for GNU Guix
  2021-09-17 17:00             ` zimoun
  0 siblings, 1 reply; 14+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2021-09-17 10:46 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 50606, zimoun

Shall we close this bug?




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-17 10:46           ` EuAndreh via Bug reports for GNU Guix
@ 2021-09-17 17:00             ` zimoun
  2021-09-18 10:08               ` Ludovic Courtès
  0 siblings, 1 reply; 14+ messages in thread
From: zimoun @ 2021-09-17 17:00 UTC (permalink / raw)
  To: EuAndreh; +Cc: 50606

Hi,

On Fri, 17 Sept 2021 at 12:47, EuAndreh <eu@euandre.org> wrote:
>
> 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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#50606: Add support for other formats of Guix channels
  2021-09-17 17:00             ` zimoun
@ 2021-09-18 10:08               ` Ludovic Courtès
  0 siblings, 0 replies; 14+ messages in thread
From: Ludovic Courtès @ 2021-09-18 10:08 UTC (permalink / raw)
  To: zimoun; +Cc: EuAndreh, 50606

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Fri, 17 Sept 2021 at 12:47, EuAndreh <eu@euandre.org> wrote:
>>
>> Shall we close this bug?
>
> I think this wish,

Done!

> Guix channel authors may want to serve channels:
> - via "Dumb HTTP" Git repositories;
>
> still makes sense.

Yes.

Ludo’.




^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-09-18 10:09 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-15 17:30 bug#50606: Add support for other formats of Guix channels EuAndreh via Bug reports for GNU Guix
2021-09-16  8:17 ` Ludovic Courtès
2021-09-16 11:18   ` zimoun
2021-09-16 17:41     ` EuAndreh via Bug reports for GNU Guix
2021-09-16 17:48       ` EuAndreh via Bug reports for GNU Guix
2021-09-16 17:51         ` EuAndreh via Bug reports for GNU Guix
2021-09-16 20:21       ` Ludovic Courtès
2021-09-17 10:41         ` EuAndreh via Bug reports for GNU Guix
2021-09-17 10:46           ` EuAndreh via Bug reports for GNU Guix
2021-09-17 17:00             ` zimoun
2021-09-18 10:08               ` Ludovic Courtès
2021-09-16 23:44       ` Leo Famulari
2021-09-17  8:16       ` zimoun
2021-09-17 10:44         ` EuAndreh via Bug reports for GNU Guix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.