GNU bug report logs - #46214
[PATCH] DRAFT: narinfo hooks for ‘guix publish’

Previous Next

Package: guix-patches;

Reported by: Maxime Devos <maximedevos <at> telenet.be>

Date: Sun, 31 Jan 2021 16:18:02 UTC

Severity: normal

Tags: patch

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: guix-patches <at> gnu.org
Subject: [PATCH] DRAFT: narinfo hooks for ‘guix publish’
Date: Sun, 31 Jan 2021 12:11:25 +0100
[Message part 1 (text/plain, inline)]
Hello Guix!

I've a proposal to make ‘guix publish’ somewhat extensible.
The draft patch allows for passing a list of ‘hooks’ to guix
publish, with "guix publish --hooks=FILE-WITH-HOOKS.scm
--hooks=MORE-HOOKS.go".  "guix publish" then will consult
this list of hooks at some points.

I've defined a ‘narinfo-hook’, which allows adding extra
key value pairs to the generated narinfos.  See the last
patch that adds a ‘hook.scm’ file for a silly example
that includes a random number and some arbitrary strings.

A TODO for a future revision of the patch, is modifying
‘guix-publish-service-type’ to allow passing a list of
hooks (as gexps).

The use case I had in mind: this could be used for Guix+IPFS
and Guix+GNUnet integration (at least on the "guix publish"
side), by implementing a hook that inserts the store item
into IPFS and GNUnet respectively, and add an appropriate
IPFS and GNUnet URI.

(I'll look into appropriate "guix substitute" hooks
later.)

Guix+IPFS and Guix+GNUnet integrations could of course
use a forked guix (until the integration is merged
upstream when it is in a good state), but a hook system
seems more practical for experimentation to me.

(Also, if hypothetically, in the future "guix publish" supports,
say, IPFS, GNUnet, BitTorrent and Dat, then using the approach
of wip-ipfs-substitutes, there would be four keyword
arguments that need to be passed everywhere.  This patch
only passes a single #:hooks argument.)

Also a question for guix-devel: the wip-ipfs-substitutes
patch adds the "IPFS: etcetera" line *after* the signed
part, while this patch only allows for addings key-value
pairs that will be signed.  Would it be problematic for
the "IPFS: etcetera" or "GNUnet: etcetera" line to be
signed?

If this proposal seems OK to guix-devel, I'll write up
some documentation, tests and changes to
guix-publish-service-type.

(Patch can also be found as signed tag wip-publish-narinfo-hook0
at https://notabug.org/mdevos/guix-gnunet.)

Greetings,
Maxime
-- 
Maxime Devos <maximedevos <at> telenet.be>
PGP Key: C1F3 3EE2 0C52 8FDB 7DD7  011F 49E3 EE22 1917 25EE
Freenode handle: mdevos
[0001-DRAFT-Support-hooks-for-adding-extra-entries-to-the-.patch (text/x-patch, attachment)]
[0002-DRAFT-add-hook-example.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 4 years and 117 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.