Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

[Adriano Peluso]

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 🤷️