Re: Overhauling the cargo-build-system

[Efraim Flashner]

On Sat, Nov 16, 2019 at 10:33:32PM +0100, Ludovic Courtès wrote:
> Hello!
> 
> Martin Becze <address@hidden> skribis:
> 
> > Sorry for digging up and old issue, but i just saw commit
> > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c
> >
> >> It makes for a very large package definition, but we
> > wouldn't have to ensure thousands of other rust libraries built so we
> >
> > The whole point of package management is that you can use module
> > building blocks. By having to specify the sub-dependencies in a top
> > level definition kinda breaks the whole modular thing. In commit
> > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c all the inputs got removed for
> > all the libraries. So if I'm trying to use guix as package manager for a
> > rust project and I want to use one of the rust libraries in
> > crates-io.scm, how am i suppose to do this? I can't just include it as
> > an input to my project because now I have to look up all of it
> > dependencies as well?
> 
> I agree that removing all the dependencies from Rust packages feels
> wrong.
> 
> What I would have liked is to somehow replace the #:cargo-inputs
> argument (which is build-system-specific and thus “opaque”) with regular
> ‘native-inputs’ or ‘inputs’ field.
> 
> I know it’s not that easy with Rust and Cargo, I just never manage to
> fully grasp why :-), but at least that should be our horizon IMO.
> 
> WDYT, Efraim, Martin, and other Rusty people?  :-)
> 

The big problems are the recursive dependencies, the partial
dependencies and the versioning. There are some that are easy to figure
out, serde always needs serde-derive, winapi always needs the
winapi-[i686|x86_64] crates, rayon -> rayon-core, etc. The real problem
is that each crate has a number of features, and only needs certain
inputs based on those features. If we include too few then we're stuck
specifying dependencies anyway. If we include all of them then we're
stuck packaging way more versions of things than we actually need. This
by itself might not be a problem; we could just say "this is what the
importer gave us based on upstream, if you're missing something you're
on your own to add it."

I have one package that I was working on, a custom rust package (which
is unfortunately still missing a license file). In the end I needed
about 70 crates. Before the change I had it building with about 200
packaged crates but the file itself failed to compile with a 'guix pull'
because of all the still unpackaged crates which were referenced by
other packaged crates. I still haven't reached the bottom of that tree,
and I have more than 500 crates that I haven't upstreamed yet.

The current situation definitely could be better. Without opening the
repo there's no way to know which crates are packaged. When updating a
crate there's no way to know which packages will be rebuilt.

I suppose one way to work around some of the issues is to make it so
that the crates "build" by copying the source to %out/share/guix-vendor
or something.

-- 
Efraim Flashner   <address@hidden>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature