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
