diff --git a/faq.md b/faq.md index ae01155e6ba4ffe00f5554a9c14171a26d743d56..ded47e981e6d4cefe1867ecc44f571cff9a4552d 100644 --- a/faq.md +++ b/faq.md @@ -907,3 +907,165 @@ R : dans la mesure où SWH récupère tout l'historique du projet -> non - Q : SWH peut-il être utilisé pour construire de grands modèles de langages (comme l'a fait par exemple GitHub pour Copilot) ? R : a priori non. Roberto: Techniquement, rien n'empêche de faire cela, mais on peut en reparler de vive voix. + +## Retrieved from emails with the authors of the Mooc "Reproducible research": use case +Description of the need: + +"Bonjour Roberto, + +[...] Dans le module 1, nous mettons en avant +les archives et les identifiants pérènes et en particulier SWH et les +swhid. Nous insistons ainsi sur l'importance d'archiver son code et de +le référencer comme il faut dans ses articles. Et c'est parfait pour +*son* propre code. Ceux qui veulent l'utiliser pourront effectivement le +trouver sur SWH et le télécharger. + +En revanche, comme nous mettons également en avant l'intérêt +d'automatiser, mettons nous dans la peau d'une chercheuse (pour +changer! n'utilisant pas (encore GUIX et qui souhaiterait +construire sur deux autres codes. De base, elle aurait mis deux wget +(ou deux git clone avec le bon sha1 ou ...) dans son Makefile pour les +récupérer de github ou de netlib. Mais c'est le "mal" car on n'est pas +sûr de la pérénité de ces URLs et elle préférerait donc utiliser des +SWHID. Comment faire en pratique ? En effet, j'ai l'impression qu'il +est difficile de faire un wget sur SWH. On a bien vu le code dans GUIX +qui passe par SWH quand il ne trouve pas ses sources, et ça marche +super bien, mais c'est un peu hardcore pour une chercheuse +"lambda". Cette dernière risque vite de se décourager et d'archiver +les deux logiciels sur Zenodo histoire que son script puisse les +télécharger directement, et ce n'est pas vraiment ce que l'on veut +encourager. + +As-tu une idée sur la bonne façon de procéder ? Je comprends bien que +SWH n'ait pas vocation à se substituer aux plates-formes classiques en +terme d'accès à la donnée et que ça impliquerait une augmentation de +la charge sur vos serveurs non négligable et non désirable. + +Du coup, on s'est aussi demandés s'il serait absurde que SWH fournisse +(quand il le peut) un service qui transforme un SWHID en un lien où +les données peuvent être téléchargées (chez github, gitlab, etc.), +charge à l'utilisateur de vérifier qu'il récupère bien ce qu'il faut, +bien sûr. + +À bientôt, +Arnaud" + +Answers: +Roberto +Voici la partie de la spec qui en parle: (et la version archivée dans SWH) :-) +Note on compatibility with Git + +SWHIDs for contents, directories, revisions, and releases are, at present, compatible with the way the current version of Git proceeds for computing identifiers for its objects. The <object_id> part of a SWHID for a content object is the Git blob identifier of any file with the same content; for a revision it is the Git commit identifier for the same revision, etc. This is not the case for snapshot identifiers, as Git does not have a corresponding object type. + +Git compatibility is practical, but incidental and is not guaranteed to be maintained in future versions of this standard, nor for different versions of Git. + +-- +Roberto + +On Mon, 2 Oct 2023 at 10:55, Roberto Di Cosmo <roberto@dicosmo.org> wrote: + + > Je peux voir que l'origine est GitHub, mais je n'ai pas le commit ID dont j'aurais besoin (parce que je ne suis pas censé savoir que le hash après :rev: est aussi le commit ID de git). + + Mais si, mais si, tu est censé le savoir, c'est meme ecrit dans la spec officielle ;-) + + -- + Roberto + + ------------------------------------------------------------------ + Computer Science Professor + (on leave at INRIA from IRIF/Université Paris Cité) + + Director + Software Heritage https://www.softwareheritage.org + INRIA http://y2u.be/Ez4xKTKJO2o + Bureau C328 E-mail : roberto@dicosmo.org + 2, Rue Simone Iff Web page : http://www.dicosmo.org + CS 42112 Twitter : http://twitter.com/rdicosmo + 75589 Paris Cedex 12 Tel : +33 1 80 49 44 42 + ------------------------------------------------------------------ + GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 + + + On Mon, 2 Oct 2023 at 09:09, Konrad Hinsen <konrad.hinsen@cnrs.fr> wrote: + + Bonjour Roberto, + + Merci pour ta réponse détaillée malgré les pressions de la rentrée ! + + > Idealement, l'outil devrait etre une sorte de "drop in replacement" + > pour un wget (on pourrait l'appeler shwget ou un truc comme c,a :-)) + > qui ferait a minima la chose suivante: + ... + + J'ai pensé à quelque chose de ce genre aussi, et il me semble que ça + devrait même être assez facile à faire, en récupérant le code dans Guix. + "Assez facile" bien sûr à interpréter dans le contexte d'un projet + logiciel ! + + Pour moi, la question de fonds n'est pas l'outil mais les bonnes + pratiques à recommander aux chercheurs. C'est ça notre rôle fondamental + avec le MOOC. + + On était parti sur l'idée de dire "citez votre code par le SWHID". + Mais avec rien que le SWHID, on ne peut pas récupérer l'URL d'origine. + Même la version contextualisée ne suffit pas. + + Exemple : + + https://archive.softwareheritage.org/swh:1:dir:41b80800574b39aa7143b1f4257bc8afdc014333;origin=https://github.com/khinsen/rescience-ten-year-challenge-paper-4;visit=swh:1:snp:65fc8b9f2c517c0450322ec85becdf2ee6064900;anchor=swh:1:rev:5c232547efd1de14ad3268946e8dcbcd6d12283c + + Je peux voir que l'origine est GitHub, mais je n'ai pas le commit ID + dont j'aurais besoin (parce que je ne suis pas censé savoir que le hash + après :rev: est aussi le commit ID de git). + + Inversement, si je cite dans mon papier l'URL de GitHub et le commit, + je peux obtenir le code par GitHub, et aussi le retrouver chez SWH + le jour ou GitHub est en panne. + + Question provocatrice : à quoi ça sert alors de citer le SWHID ? + + Je sais bien que ça donne des infos supplémentaires, parfois utile, mais + est-ce que cette utilité est suffisante pour recommander une pratique + plus lourde et plus à risque d'erreurs ? + + A bientôt, + Konrad. +Roberto: +Bonsoir Arnaud, + desole pour la reponse tardive, on est bien sous pression, comme +l'on se doit lors d'une rentree :-) + +Je vois tout à fait ton use case, et AMHA cela se prete bien au +developpement d'un petit outil qui implemente le mechanisme de +fallback sur SWH prévu dans guix/nix. + +Idealement, l'outil devrait etre une sorte de "drop in replacement" +pour un wget (on pourrait l'appeler shwget ou un truc comme c,a :-)) +qui ferait a minima la chose suivante: + +1) essayer de telecharger depuis l'URL normale +2) en cas d'échec, faire un fallback sur SWH, en utilisant l'API pour le + "Vault", i.e.: https://archive.softwareheritage.org/api/1/vault/flat/doc/ + pour demander la préparation de l'archive, et en implementant toute + la logique necessaire pour "attendre" que l'archive soit pret avant + de le telecharger + +A noter qu'on garde un cache pour le vault, donc une fois que le .tar.gz +est fabrique, les demandes suivantes vont aller vite tant qu'il reste +dans le cache. + +Pour que cela fonctionne, il faut quand meme connaitre le SWHID 'directory' +du contenu recherche, et bien evidemment, que le contenu soit archive +avant, donc il faut passer l'URL et le swh:1:dir correspondant en +ligne de commande, ce qui peut etre lourd à faire. + +Du coup, l'outil pourrait etre un peu plus evolue: si l'URL normale +fonctionne et pointe sur un depot git, et qu'on ne passe pas le swhid +en parametre, il pourrait declencher un save code now, et recuperer +le bon swhid pour la directory en question (e.g. en utilisant GraphQL +pour l'archive), et se rappeler de cela dans un fichier de config. + +A creuser, donc: s'il y a des volontaires pour implementer, je +veux bien donner des idees, meme si je n'ai pas la bande passante +pour implementer cela moi meme +