The rust:cargo output - why?

The rust:cargo output - why?

[Jakub Kądziołka]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Hi Guix,

I have noticed that the procedure we use to install cargo to a separate
output in the Rust definition has started rebuilding quite a large part
of the compiler when the prefix is changed starting in Rust 1.34. I have
asked around, and upstream doesn't support any straightforward way of
installing cargo to a separate prefix:

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Installing.20cargo.20with.20a.20different.20prefix

I have some hacks in mind that could allow us to keep installing cargo
into a separate output without the extra rebuild, such as building the
compiler with --keep-stage or installing cargo with a DESTDIR and
manually moving the files. However, none of these, including the current
solution, are without tradeoffs. This makes me wonder - why not put
cargo in :out?

In my experience with using Rust, cargo is an integral part of the
toolchain and I find it quite unlikely that anyone would find bare rustc
useful. Indeed, rust is depended upon explicitly by cargo-build-system,
icecat and icedove, and all of these also use the cargo output.
User-facing usage is even more likely to use cargo.

As such, I would like to suggest that we merge rust:out and rust:cargo
on staging.

`guix size rust rust:cargo` reports that the closure would increase from
600 to 700 MiB.

Thoughts?

Regards,
Jakub Kądziołka

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: The rust:cargo output - why?

[John Soo]

Hi Jakub,

I agree.  

In my mind, anything that would be installed via rustup add component would be a separate output. 

Aside from that, to reduce closure size, Maybe the docs can go into a separate output?

But cargo is quite integral to the rust workflow I was very confused by cargo as a separate output for a long time. 

- John