[bug#51845] Using ‘native-inputs’ and ‘inputs’ for Cargo packages?

[Ludovic Courtès]

Howdy!

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Mon, Dec 06, 2021 at 11:17:47PM +0100, Ludovic Courtès wrote:

[...]

>> With the minimal changes to (guix build-system cargo) below, one can use
>> either the current style or pass “development inputs” as ‘native-inputs’
>> and other dependencies as ‘inputs’.  Source transitivity is preserved
>> but you can write packages the normal way.
>> 
>> I modified some of the dependencies of librsvg to use
>> native-inputs/inputs and you can see when applying this part of the
>> patch that the librsvg derivation is unchanged.  Good thing is that
>> ‘guix graph’ and ‘guix refresh -l’ work for these packages.
>> 
>> Is this a direction we want to take?
>
> I like the way it works out, and has Guix do the magic to give us the
> crates in the graph. On the other hand I tried changing the cargo-inputs
> from librsvg to regular inputs, and after 2.5 minutes of trying to run
> `guix show librsvg` I still wasn't seeing the dependencies and my RAM
> usage was still increasing. Also gnu/packages/gnome.scm didn't fail to
> compile, so there was no notice of the loop.

Notice that the dependency cycle, as discussed on IRC, breaks things
like ‘guix show’ (?) and ‘guix graph’, but doesn’t break actual package
builds because it’s a <package> cycle that vanishes once packages are
lowered to bags and derivations.

Regardless, it would be nice not to have cycles in the first place.

[...]

> So to summarize, between your diff to treat inputs built using
> cargo-build-system as cargo-inputs and my changes to save previous
> crates for the next input we reach a place where we can start to change
> the crates over to use inputs and native-inputs instead of cargo-inputs
> and cargo-development-inputs without needing to flip everything at once.

What are the “changes to save previous crates for the next input”?

> So I'd go with it's good, but I'm not sure it directly works to fix the
> problem we're having with librsvg.

No no, it’s completely unrelated to the librsvg issue, which is why I
changed subject lines.  :-)  I think it’d be nice to have anyway.

>> +(define (cargo-input? input)
>> +  (match input
>> +    ((label (? package? p))
>> +     (eq? cargo-build-system (package-build-system p)))
>> +    (_ #f)))
>> +
>
> I would've sorted based on the name starting with 'rust-'.

OK.

[...]

>>  (define (package-cargo-inputs p)
>> -  (apply
>> -    (lambda* (#:key (cargo-inputs '()) #:allow-other-keys)
>> -      cargo-inputs)
>> -    (package-arguments p)))
>> +  (match (member #:cargo-inputs (package-arguments p))
>> +    (#f (filter cargo-input? (package-inputs p)))
>> +    ((_ inputs . _) inputs)))
>>  
>>  (define (package-cargo-development-inputs p)
>> -  (apply
>> -    (lambda* (#:key (cargo-development-inputs '()) #:allow-other-keys)
>> -      cargo-development-inputs)
>> -    (package-arguments p)))
>> +  (match (member #:cargo-development-inputs (package-arguments p))
>> +    (#f (filter cargo-input? (package-native-inputs p)))
>> +    ((_ inputs . _) inputs)))
>
> I see we don't get rid of #:cargo-inputs or #:cargo-development-inputs.
> So even if applying the style change to all the crates causes circular
> dependency problems we can fall back to the current method. I ran into
> problems once I hit all the rust-bindgen crates.

Right.  Support for #:cargo-development-inputs and #:cargo-inputs is
here so we could have a smooth “upgrade” without breaking compatibility.

Anyway, I think the priority is to get ‘core-updates-frozen’, which
probably involves either pinning librsvg dependencies or using the
bundled libraries as you showed at the beginning of this thread.
We can resume work on prettified Rust packages after that; it’ll be
useful to be able to use ‘guix refresh -l’.

Ludo’.