I have released the first, experimental, proof-of-concept version of Rustbud, a tool for managing Rust toolchains (the rustc compiler, cargo, documentation, etc.)
Rustbud is similar to the official rustup, but is designed to be composable, repeatable and predictable. For example, rustup encourages sharing a single toolchain across all your Rust projects, so a change made for one project might break another. Rustbud encourages each project having its own toolchain, so it always works the same way regardless of what other toolchains might be around or how they're configured.
I announced this a few days ago on Reddit, and the overwhelming feedback was "you should put a comparison with rustup at the top of the README", so there's now a comparison with rustup at the top of the README.
rustup expects you to share the same few environments
across all your projects.
I think that it's worth mentioning that you can use rustup override add to pin a particular toolchain to a particular project, though it's indeed not the default
I'm simultaneously wildly enthusiastic that someone is trying new, potentially better, ways of packaging "the rust experience", and also doubtful if it is maybe too early to be splitting the ecosystem.
But I think the enthusiasm will prevail: trying more things can only inspire better solution! Great going!
excellent point
Although, as an avid OpenSUSE, CentOS, Debian and Ubuntu user, I still prefer rustup, for that cutting-edge-dripping-with-blood feeling. For example, I wouldn't want to live without compile_error!() anymore, and that's only in since 1.20
Though I'm inclined to give rustbud a spin too, just to see what it feels like!
Yeah, I will be at least a little surprised if Rustbud ever gains a userbase of more than one. However, the ideals of "composable, reliable, predictable" are ones I feel pretty strongly about, and if somebody reads about Rustbud and goes off to make their own, more successful thing based on similar principles, I'll consider that a victory.
When I started playing with Rust, I was very impressed with Cargo and how it managed to provide strict, repeatable builds while maintaining a fairly friendly user-interface. In a way, Rustbud is my attempt to make a Cargo-style package-manager for the Rust toolchain, not just for Rust crates. From that perspective, Rustbud's ideas aren't that novel.
I would wager that if you were an avid Arch Linux, OpenSUSE Tumbleweed and Debian Unstable user, your point of view on this matter could differ slightly.
On a rolling release, the convenience of automated updates and integrated package management can be worth waiting a week or two for a fresh package to land... precisely because it takes a couple of weeks, and not six months and a painful system upgrade procedure as on stable release based distros.
Of course, if you need a nightly toolchain, that's a different story. For this use case, rustup will always have a strong edge. But the OSX and Python communities taught me the hard way the importance of sticking with unified package management whenever you can get away with it.
I'm not sure I've understood you correctly, or have maybe expressed myself inadequately. I meant to say that, even as an avid linux user (Debian Stable, and a fairly static CentOS at work, but rolling OpenSUSE tumbleweed at home), I still prefer the rust toolchain to using the system package managers for Rust. I'm not even necessarily on Rust Nightly.
My experience so far with python's VirtualEnv, Groovy's SDKman and Ruby Bundlr has been that none of them integrate nicely with the "local" package manager of choice. Rustup/Cargo currently have the same problem.
My solution thus has always been to treat each programming language as its own, self-contained bubble as much as possible, doing things the way the language-specific tools prefer, rather than trying to shoehorn them into my OS-packager.
If I may hazard a guess to where I misunderstand you, my programming has never had to interface (much) with the local system, as it's been server-side software that must be installed on other computers, and maybe the occasional trival desktop application.
I concede that, if I were to need more system-dependencies (QT/GTK? OpenSSL? FUSE?) I would probably appreciate a better tie-in with the OS-provided packages.
In my experience, distro-packaged dependencies versus custom dependencies boils down to what you're using it for. A former employer was a Python-and-CentOS shop, and the hassle of dealing with non-CentOS Python packages was definitely worth it because of the third-party libraries we wanted to use and all the fancy things added to Python since the last version of CentOS was released. On the other hand, when we wanted to run third-party tools supplied as Java JARs, we sure as heck wanted to use the OS-provided packages for Java, because we didn't want to learn the quirks of yet another packaging system.
I imagine people that just want to build some Rust software (say, because a Ruby or Node.JS or Python library uses it for performance) will want to use the system-provided Rust toolchain. People that are actually developing Rust software from scratch will likely want to use Rustbud or rustup, or the Nix package manager, or something like that.
Rustbud is, at least in part, inspired by the hoops I had to jump through to do reliable Python builds and deployments in a commercial setting.
This reminds me of the now-defunct multirust, which was my first introduction to toolchain management in Rust. @Screwtapello would you consider Rustbud, maybe in some ways, a "spiritual successor" to the multirust? Or just philosophically similar? I ask because your readme makes no mention of multirust (I'm not sure it's worth referencing, these days), but I see some pretty clear parallels in feature set.
By the way, the declarative environment file is an awesome idea! One of the things I frequently struggle with at work is ensuring that all builds (regardless of language) are purely reproducible. This seems like a good way to address that particular situation with Rust.
multirust.sh to manage multiple toolchains (which used rustup.sh)
multirust.sh was then rewritten in Rust (multirust.rs) without dependency on rustup.sh. Later, multirust.rs was renamed to rustup.rs, since this was considered the better name and the original rustup.sh wasn't necessary anymore.
