Il giorno mar, 01/06/2021 alle 13.03 +0200, Leo Prikler ha scritto: > Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso: > > Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > > > The output could be a collection of .tar.gz files distributed > > > > through > > > > ipfs, bittorrent, syncthing or rsync > > > > > > > > Not necessarily packages in the way Guix intends them > > > > > > > > I understand there's already some work going on to reproduce > > > > tarballs > > > > in a format convenient to Guix (maybe with proper hashes and > > > > metadata > > > > ?) for when they get erased by distributors > > > Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch > > > etc. > > > as > > > methods or fallbacks, but this doesn't solve the problem that's > > > posed > > > here. You can't just pull the complete source closure of e.g. > > > Fractal > > > over the ether and pretend it's just one package. > > > > Probably the Fractal package will depend on some others, so it's > > gonna be a collection 🤷️ > > > > Doesn't that happen already for traditional tarballs ? > We don't stuff tarball collections into packages. We stuff inputs > into > packages and one input equals one tarball. > > > > We already drop all > > > vendored dependencies from tarballs, that aren't created by Rust > > > et > > > al., this does the exact opposite. > > > > I'm not sure I understand > > > > This does the opposite ? > > > > How so ? > Let's assume we form this sexp-pack and use it as input to some > package. What happens?
we wouldn't use a sexp-pack as an input to a guix package in the same way as, as you noticed, we don't feed tarballs as inputs to guix packages A Guix package doesn't depend on some tarballs. It depends on some other Guix packages In the same way, a Guix package wouldn't depend on a sexp-pack. You can think of sexp-pack as an alternative format to tarball With, maybe, some more metadata For example, a sexp-pack could contain a hash of itself and hashes of other _sexp-packs_ it depends on Similarly to how, for example, python packages on pypi express dependecies on other packages in pypi The difference is that, as far as I understand, python packages (those in pypi, not those in Guix) express dependencies in a somewhat loose way Guix packages are stricter sexp-packs could be stricter too, bringing part of the data reconciliation outside of Guix A Guix importer could recursively import sexp-packs the same way the python importer... I'm assuming that a Rust package can be built in a sane way, with dependencies properly sorted out. I know that's possible for javascript packages, I'm not sure about Rust Such a data/packages collection could be used by mainstream linux distributions too, as far as I understand 🤷️