How does rust workflow integrate into gentoo?

[epenguin]

I'm asking this because i saw the desktop profile includes a build of rust and llvm. Does gentoo build these?

I notice that I am missing rustup, but I have cargo and rustc installed already. If I go and install rust from the official rust-lang install site, I get rustup. Do I even need rustup? Or should I just use USE flags to specify toolchain and architecture and stuff. I have the documentation open in front of me. I'm more asking what I should do, and less of how do I do a thing.

[alamahant]

Are you a rust aficionado?
If not just emerge rust-bin and forget about rust.

It is only pulled by
gnome-base/librsvg
In my case.

[epenguin]

Are you a rust aficionado?
If not just emerge rust-bin and forget about rust.

It is only pulled by
gnome-base/librsvg
In my case.

I wouldn't say I'm an aficionado because I'm quite terrible at rust, but I do see it as essential to development right now. I guess there aren't many people that like rust on gentoo, so this might've been a dumb question

[Hu]

I'm asking this because i saw the desktop profile includes a build of rust and llvm. Does gentoo build these?

Please clarify the question. Portage runs all package ebuilds locally. If you're not installing a prebuilt binary, such as rust-bin, then yes, you build it locally.

I notice that I am missing rustup, but I have cargo and rustc installed already. If I go and install rust from the official rust-lang install site, I get rustup. Do I even need rustup? Or should I just use USE flags to specify toolchain and architecture and stuff. I have the documentation open in front of me. I'm more asking what I should do, and less of how do I do a thing.

You should avoid Rust as much as possible until they get their distribution story straightened out. Recommending people to curlpipesh is just crazy.

Unless you plan to use Rust beyond what Portage requires of you (due to needing rusted packages), I would ignore Rust upstream and let Portage pull what it needs, when it needs it. Trying to co-install upstream Rust compilers and Portage rust packages will probably just get you in trouble. As far as I know, upstream's rustup doesn't integrate properly with any package manager, so there's no way to have it advise Portage about out-of-tree tools installed by rustup.

[sam_]

Feel free to use rustup (it's packaged for a reason) but it is not a replacement for the system copy of Rust which allows Portage to reason about its version and for us to ensure it's compatible with packages & integrates well with Gentoo (e.g. filesystem layout).

(I was surprised that using rustup is fine, but I've checked, and it is, according to the rust@ team in Gentoo. The important thing however is to make sure it doesn't infect your emerges with any set environment variables.)

[epenguin]

What I'm taking from this is Gentoo handles the installation (compilation) of the rust toolchains, so I don't need rustup. I do plan on using Rust beyond what Portage requires because I use it for development.

As far as I know, upstream's rustup doesn't integrate properly with any package manager, so there's no way to have it advise Portage about out-of-tree tools installed by rustup

This answers my question indirectly. I guess my real question was "Should I install rustup and have it install binary versions of stuff", but I think you answered that pretty clearly. I suck at asking questions in new territory

You should avoid Rust as much as possible until they get their distribution story straightened out. Recommending people to curlpipesh is just crazy.

I wish I would've known this before I dove into the language a couple years ago =(

[Hu]

Don't feel too bad. Rust is amazingly popular, considering some of their strange choices.

[pjp]

Rust is amazingly popular, considering some of their strange choices.

I'm no topical expert... is that not accurate of most languages? Despite language choices, JavaScript gained popularity because of the web. Rust also (even if indirectly). C because it was better than alternatives and suitable for the audience at the time. C++ because "let's create a standard so we don't have so many standards". Perl, Haskell, Go and Erlang. All seem to qualify.

[Leonardo.b]

It is only pulled by
gnome-base/librsvg
In my case.

A librsvg-bin package may be a good alternative, if you are OK with using binaries.

Maybe you can avoid librsvg enterely.
I have a patched GTK+, and I use only "binary" icon packages (why to build them from source?).
Then it depends on which other software you run.

You should avoid Rust as much as possible until they get their distribution story straightened out. :) Recommending people to curlpipesh is just crazy.

:)

[epenguin]

Following up on this because I've discovered some things (?). Portage basically completely replaces rustup, which is pretty cool. So when I would normally say

Code: Select all

rustup install clippy
rustup install rustfmt

I can just add these to my USE flags. I am, however, confused because it doesn't seem to want to respect my nightly and my parallel-compiler use flags.

/etc/portage/package.use/penguin.use

Code: Select all

#package.use
x11-base/xorg-server xorg elogind

media-sound/pulseaudio alsa-plugin bluetooth

app-editors/emacs xft

dev-lang/rust nightly rls rustfmt rust-src clippy parallel-compiler

Code: Select all

penguin@gpenguin ~ $ sudo emerge -apv dev-lang/rust

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-lang/rust-1.56.1:stable/1.56::gentoo  USE="clippy* rls* rust-src* rustfmt* -debug -doc (-miri) (-nightly) (-parallel-compiler) (-system-bootstrap) (-system-llvm) -test -verify-sig -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -AVR -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB

It's still wanting to omit nightly and parallel-compiler for some reason.

[Ionen]

It's still wanting to omit nightly and parallel-compiler for some reason.

nightly is masked in stable, and currently parallel-compiler is masked everywhere, you can force them back on if really wanted albeit it's at your own risks (especially for parallel-compiler right now)

From /var/db/repos/gentoo/profiles/base/package.use.stable.mask:

Code: Select all

# For bleeding edge features and testing, not generally suitable
# for stable systems
dev-lang/rust miri nightly system-bootstrap

If wanted to allow these you can either

A) Create the opposite of the above line using the same file in /etc/portage/profile, e.g. in /etc/portage/profile/package.use.stable.mask to remove the nightly mask:

Code: Select all

dev-lang/rust -nightly

Then enable it normally in your package.use

B) add dev-lang/rust and virtual/rust to your /etc/portage/package.accept_keywords, which allows portage to use unstable features and versions -- although using ~testing versions in stable may have unforeseen consequence (like perhaps a fixed package for new rust is still in ~testing too and will get build failures with the stable version).

For parallel, it's in profiles/package.use.mask instead:

Code: Select all

# parallel-compiler feature is not tested by upstream
# and is not recommended for general usage and may silently
# miscompile code if used (unlikely, but not impossible)
# feel free to unmask, but be prepared to deal with possible bugs
# https://bugs.gentoo.org/813954
# https://github.com/rust-lang/rust/issues/89108
dev-lang/rust parallel-compiler

[epenguin]

It's still wanting to omit nightly and parallel-compiler for some reason.

nightly is masked in stable, and currently parallel-compiler is masked everywhere, you can force them back on if really wanted albeit it's at your own risks (especially for parallel-compiler right now)

From /var/db/repos/gentoo/profiles/base/package.use.stable.mask:

Code: Select all

# For bleeding edge features and testing, not generally suitable
# for stable systems
dev-lang/rust miri nightly system-bootstrap

If wanted to allow these you can either

A) Create the opposite of the above line using the same file in /etc/portage/profile, e.g. in /etc/portage/profile/package.use.stable.mask to remove the nightly mask:

Code: Select all

dev-lang/rust -nightly

Then enable it normally in your package.use

B) add dev-lang/rust and virtual/rust to your /etc/portage/package.accept_keywords, which allows portage to use unstable features and versions -- although using ~testing versions in stable may have unforeseen consequence (like perhaps a fixed package for new rust is still in ~testing too).

For parallel, it's in profiles/package.use.mask instead:

Code: Select all

# parallel-compiler feature is not tested by upstream
# and is not recommended for general usage and may silently
# miscompile code if used (unlikely, but not impossible)
# feel free to unmask, but be prepared to deal with possible bugs
# https://bugs.gentoo.org/813954
# https://github.com/rust-lang/rust/issues/89108
dev-lang/rust parallel-compiler

That did the trick. Left out parallel-compiler for now though. Thanks!

[Etal]

If you do Rust development, one reason to install dev-util/rustup is because some IDEs like IntelliJ IDEA (or CLion) use the rustup command to find where rust toolchains are installed. If you don't have it, every time rust is updated you will need to manually update the location of stdlib sources. With rustup installed, it's done automatically,

The rustup command wouldn't be run as root, so it would not mess up your system rust compiler. If you wanted to, you would use it to install toolchains in your user's home directory. But you don't have to - if you select the needed USE flags, Gentoo's rust toolchain works just fine.

I have official stable toolchain installed for testing purposes, but keep the system one as default:

Code: Select all

$ rustup toolchain list
stable-x86_64-unknown-linux-gnu
gentoo (default)

[Hu]

Rust is amazingly popular, considering some of their strange choices.

I'm no topical expert... is that not accurate of most languages? Despite language choices, JavaScript gained popularity because of the web. Rust also (even if indirectly). C because it was better than alternatives and suitable for the audience at the time. C++ because "let's create a standard so we don't have so many standards". Perl, Haskell, Go and Erlang. All seem to qualify.

All languages have some quirks, but some languages failed because their quirks were worse than their competitors' quirks. I don't see large Perl programs much anymore. I've never seen a large tcl program. I think Erlang is popular in telecom, but I've never seen an open source program that uses it. Similarly, Haskell has some adherents, but I've never seen a popular program call for it. My complaint with Rust is that they started it after a number of bad practices were well understood, and seem to have used that list of bad practices as a checklist of things to do, not things to avoid. They had access to decades of experience, and yet acted like they knew better than everyone else.

[GDH-gentoo]

C++ because "let's create a standard so we don't have so many standards".

Huh?

[pjp]

All languages have some quirks, but some languages failed because their quirks were worse than their competitors' quirks. I don't see large Perl programs much anymore. I've never seen a large tcl program. I think Erlang is popular in telecom, but I've never seen an open source program that uses it. Similarly, Haskell has some adherents, but I've never seen a popular program call for it. My complaint with Rust is that they started it after a number of bad practices were well understood, and seem to have used that list of bad practices as a checklist of things to do, not things to avoid. They had access to decades of experience, and yet acted like they knew better than everyone else.

I did stretch the definition of popular toward the end, but felt like they still worked as examples. I thought about mentioning Java and something else, but didn't have an immediate example of "strange choices." Perl may not be popular now, but it was very popular for quite a while, despite sigils and TIMTOWTDI, so that's why I thought it made a good example. I'm certainly not disputing any constructive criticism of Rust, only that it seemed almost like Tradition to have the strange quirks. That out of the way, I have no idea which strange choices may be comparable to your example of "things to do / avoid based on decades of experience." That distinction does clarify a difference from one strange choice and another. Thanks for clarifying.


@GDH-gentoo,

Pick something you feel can be described by "strange choices" and think of that instead. Specifics aren't the point. With the caveat that referencing multiple languages and not being too specific was intended to avoid triggering a Technology Holy War, I was referring to its expanding standard which results in multiple standards, in turn resulting in a whole "too big to know," thereby resulting in people choosing a subset of the language, which in turn effectively results in more "standards."