[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [swh-devel] Call for public review - SWH Nix/GNU Guix stack
From: |
Simon TOURNIER |
Subject: |
RE: [swh-devel] Call for public review - SWH Nix/GNU Guix stack |
Date: |
Fri, 12 Jan 2024 18:42:04 +0000 |
Hi,
> The initial NixGuix loader (currently in production) lists and loads
> origins from a manifest, ignoring the specific origins mentioned above. The
> new stack will be able to ingest those origins. It will also optionally
> associate, if present, a NAR hash (specific intrinsic identifier to Nix and
> Guix) to what’s called an ExtID (SWH side).
Cool! Thank you.
> Regarding the SWH API reading side of the ExtID though is a work to be done.
In short, currently Guix relies on SWH API for resolving from
“something” to SWHID, where “something” can be:
+ Git label tag + url
+ Git commit hash
+ plain url
Well, the situation is in good shape IMHO – I do not have recent
numbers, say all is fine for 75% of all Guix packages and for 90% of
Guix packages coming from some Git repositories – but still, we have
examples where “Git label tag + url” fails. For one instance, see [1]
pointed by [2].
The information – history of history – is there in SWH but it would
require on Guix side to parse the snapshot information and extract as
best as possible; trying several SWH snapshots until a match. Something
like that. Chance of success until completion? Weak. :-)
Moreover, what about the missing 25%? They are Guix packages coming
from Mercurial repositories or from Subversion repositories or some
others.
Back on October 2020, we had discussion [3] for sending a save request
for packages using SVN checkouts but at the time we did not have a clear
path for retrieving. Then on March 2023, maybe an path for retrieving
with this discussion [4]… but still many hacks are required [5].
Again, the information is there in SWH but it would require on Guix side
to parse the snapshot information and extract as best as possible;
trying several SWH snapshots until a match. Something like that.
Chance of success until completion? Weak. :-)
If only one source is missing, all the castle potentially falls down. Somehow,
a dictionary from ExtID as nar hash to SWHID would help to have the
castle more robust. :-)
The SWH archive coverage of Guix packages would not be 75% because we, on
Guix side, are not able to know or retrieve these missing 25%. Such dictionary
could reinforce the bridge between reproducible computational environment
and archiving, IMHO.
So yeah, we are looking forward to some ExtID interface. :-)
Cheers,
simon
1: https://issues.guix.gnu.org/66015#0-lineno53
2:
https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_148587
3: https://issues.guix.gnu.org/43442#9
4: https://sympa.inria.fr/sympa/arc/swh-devel/2023-03/msg00009.html
5: https://issues.guix.gnu.org/43442#13