[Idea] The Rust Platform Distribution

[sebasmagri]

Hi, and sorry if the following notes are a little bit sparse.

I’d like to share an idea of building a distribution of Rust, RPD in the following paragraphs, that came to my mind today. This is influenced by what other ecosystems are already doing. Some examples of this include the Haskell Platform and several examples for Python.

The RPD could be distributed as a cross platform bundle installer that would give offline access to curated tools and crates. This could include:

• An LTS toolchain depending on the installer architecture/platform.
• UI for Windows/Mac/Linux/Web (Rust Dashboard)
  • Check rustup status and update toolchains (probably with a custom LTS channel)
  • Update binaries and tools (ala cargo install-update)
  • The Book and Docs
    • Builtin offline documentation browser
• Compiler errors linked to included documentation in the Rust Dashboard (see below): this would require revamping the error messages to include error codes that can be linked easily. This would allow the default toolchain channels to distribute error messages with links to online docs, then the base URL could be customized for the RPD using a custom URL scheme to automatically open the Dasboard’s documentation browser.
• Pinned and possibly precompiled versions of the distribution crates
  • These should be all curated, 1.0 quality level crates (Libz Blitz)
• Cargo
  • With support to use the included crates by default and handle upgrades from the Web and probably some RPD specific subcommands
• RLS and editor plugins
• Clippy
• rustfmt

All the included tools and crates should go through a security audit and offer long term support.

The RPD could provide spins, like Fedora’s, for specific areas: Scientific, Data Science, WebDev, OSDev, GameDev, Embedded.

[jimmycuadra]

Sounds like a combination of The Rust Platform and rustup (with expected future components like RLS, clippy, and rustfmt).

[sebasmagri]

@jimmycuadra thanks! I had looked for something similar without success… Yes, it’s pretty much in the same direction.

[steveklabnik]

Sadly (IMO), this was very much not well received, and so we didn’t go in that direction.

[sebasmagri]

Right, I went thru @aturon’s thread and there are a bunch of good points there on why not to do it. Actually I believe that’s a nice opportunity to start implementing some of the ideas in the current tooling that might add value to the ecosystem without needing to implement the whole idea.

For example, I believe that having a toolchain and a set of crates with LTS support and stable tooling could make it easier for Linux/BSD distributions to ship and support Rust in their products…

I remember a discussion about ABI backward compatibility in the GNOME+Rust Hackfest in Mexico City, and I might be wrong but probably having something like this could be a good option for GNOME and distributions to work together with Rust’s upstream on a stable base for their releases’ lifetime.

I understand this probably wont happen without some desirable features in stable, but I still believe there are bits that could be implemented. For example I miss better offline support for the tooling on almost every single meetup or workshop I do… And I believe this improvement could also make Rust more attractive for the enterprise.

[jntrnr]

@steveklabnik - iirc, some of the reason it wasn’t as well received may have been around the framing we used.

Looking through the feedback users gave us in the survey, they’re definitely a strong desire for something along these lines, but perhaps it’ll take a few tries to strike the right balance.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.