# New-Style Chocolatey Packages \[windows\] **URL:** \ **Category:** tools and infrastructure\ **Created:** [April 25, 2019, 8:36pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890 "2019-04-25T20:36:14Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [April 25, 2019, 8:36pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/1 "2019-04-25T20:36:14Z")
Prompted by [Maturing installation options](https://internals.rust-lang.org/t/maturing-installation-options/9887) but wanting to discuss this thing separately, I’m beta testing a new way of installing Rust on Windows. ## What’s the current situation Rust distributes its packages in basically three ways: raw tarballs (which rustup uses), an MSI (which I assume is derived from the raw tarballs), and rustup itself. The current Chocolatey packages are based on the MSI. _Packages_ plural: one of them is for the MSVC toolchain, while the other is for the MinGW toolchain. I’m not actually planning to change that part, though. You can try these packages just by running `choco install rust` or `choco install rust-ms`. This is what I inherited from the previous maintainer, who apparently switched off of Windows entirely and stopped maintaining them. There are two big problems caused by using the MSI: - [Portable and user-local installs](https://github.com/chocolatey/choco/wiki/ChocolateyFAQs#what-distinction-does-chocolatey-make-between-an-installable-and-a-portable-application), which are some of the coolest parts of Chocolatey, are impossible for MSIs. - Portable installs are the best way to have Chocolatey manage multiple versions of the same application. - Upgrades don’t work right. Chocolatey assumes that newer MSI installers will perform in-place upgrades of the older ones (this is what Firefox’s installer does, for example). Rust’s don’t, so you wind up with multiple installations of Rust on your system, and no easy way to distinguish between them. ## What’s the difference with the new packages The new pre-release packages, that you can find [on my GitHub page](https://github.com/notriddle/notriddle-chocolatey-packages/), are built from the combined [https://static.rust-lang.org/dist/2019-02-28/rust-1.33.0-x86\_64-pc-windows-msvc.tar.gz](https://static.rust-lang.org/dist/2019-02-28/rust-1.33.0-x86_64-pc-windows-msvc.tar.gz) tarball directly. As such, extra components like clippy are included by default, where they weren’t before. More importantly, though, Chocolatey now keeps track of all of the package’s files, the same way a `.deb` or a `.rpm` would. And it’s way better. The packages are now portable. `choco up` now actually upgrades the packages. And, to top it all off, the installation takes about the same amount of time in spite of technically installing more stuff. To try them out, - Install Chocolatey if you don’t already have it - Check out my GitHub repo. [https://github.com/notriddle/notriddle-chocolatey-packages/](https://github.com/notriddle/notriddle-chocolatey-packages/) - Go into the `rust` or `rust-ms` directory - Run `choco pack` - Run `choco install -s . (rust|rust-ms)` - Try building Rust projects What’s in the repo? - rust and rust-ms are actually _generated_ by the script in \_update. - the two ps1 scripts at the top (update.ps1 and push.ps1) are scripts to help make maintenance easier. - the script in \_update/update.py is what generates the rust and rust-ms package metadata. It’s written in python, because python has a good toml parser that can be installed using pip, unlike the DLL that I would need to install if I wanted to parse toml from powershell (I probably could have done what I wanted with a visual studio project, but don’t even know C#, and it’s not like I’m requiring the end-users to install Python). ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [April 25, 2019, 8:41pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/2 "2019-04-25T20:41:11Z")
CC @kornel, who opened the original topic, and @retep998, who is heavily involved in Rust on Windows. ---
**Author:** ![mosh](https://avatars.discourse-cdn.com/v4/letter/m/bc8723/32.png) [@mosh](https://internals.rust-lang.org/u/mosh)\ **Post date:** [April 26, 2019, 8:05am UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/3 "2019-04-26T08:05:34Z")
Is there plan to change default to msvc? ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [April 26, 2019, 6:50pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/4 "2019-04-26T18:50:16Z")
Eventually, yes. My actual plan is for `rust` to become a virtual package, which can be fulfilled using either `rust-ms` or `rust-gnu`. This not only seems like the correct way to do it, so we can have other Chocolatey packages that happen to depend on `rust` without caring about a particular version, but also the way with the smoothest transition path. We can start by making `rust` a virtual package, while having the default version be `rust-gnu`, so when existing users of the GNU version perform an upgrade, they’ll still be on the GNU version. After awhile, we can switch to having `rust-ms` be the default, but at this point all the `rust-gnu` users will already have it, so they won’t automatically switch. The only people who will be adversely impacted will be people who regularly re-provision Windows boxes from scratch using Chocolatey, but if they’re doing that without version pinning, then they’re beyond help. ---
**Author:** ![mosh](https://avatars.discourse-cdn.com/v4/letter/m/bc8723/32.png) [@mosh](https://internals.rust-lang.org/u/mosh)\ **Post date:** [April 26, 2019, 7:43pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/5 "2019-04-26T19:43:52Z")
Thank you for explantion about your plan. It sounds great! I have another question. Do you have plan to provide rustup on chocolatey? ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [April 26, 2019, 8:34pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/6 "2019-04-26T20:34:46Z")
Somebody else already did that. [https://chocolatey.org/packages/rustup](https://chocolatey.org/packages/rustup) Personally, I think it misses the point. Half the point of Chocolatey is to use it as part of a larger configuration management system, which probably doesn’t know anything about rustup. The other half is the ability to upgrade your entire system by running `choco up`, which might upgrade rustup but won’t actually upgrade rustc. What I am thinking of? Writing a script that pretends to be rustup, offering enough commands so that IntelliJ can find your Rust installation, but still leaving the actual package management up to Chocolatey. Or, alternatively, Rust should integrate enough introspection hooks elsewhere so that IntelliJ doesn’t need to know about rustup. ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [April 28, 2019, 7:44pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/7 "2019-04-28T19:44:10Z")
> [@notriddle](#): > > What I am thinking of? Writing a script that pretends to be rustup, offering enough commands so that IntelliJ can find your Rust installation, but still leaving the actual package management up to Chocolatey. Or, alternatively, Rust should integrate enough introspection hooks elsewhere so that IntelliJ doesn’t need to know about rustup. If `rustc` is in `PATH`, IntelliJ should just work. Pretending to be rustup is probably a bad idea, b/c IntelliJ will assume it is a real rustup and will offer UI for switching toolchains, and will use (I think) the `+stable` syntax automatically. ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [April 28, 2019, 7:50pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/8 "2019-04-28T19:50:31Z")
Welp, I am forgetting things… rustup is pretty important for one thing: getting sources of the standard library. IntelliJ tries to find sources in `rustc --print-sysroot`, and, if it fails, it’ll try to run `rustup component add rust-stc`. If choco puts sources to sysroot, everything should “just work” (or, at most, a minor adjustment should be done to IntellIJ to try to fetch sources from sysroot even in non-rustup toolchains). What wouldn’t work is automatic downloading of sources if they are absent. ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [May 1, 2019, 8:51pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/9 "2019-05-01T20:51:10Z")
Note to the reader: It’s not `--print-sysroot`, it’s `--print sysroot`, with a space. Also, given what matklad said, I’m going to go with the stupid option: unconditionally install the source code. It’s not that big compared given we’re already unconditionally installing the docs, and it solves the intellij configuration problem. ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [May 1, 2019, 10:09pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/10 "2019-05-01T22:09:56Z")
@matklad I’m having trouble with IntelliJ-Rust. - It seems to have found rustc and cargo, since it reported the toolchain as being located in `C:\ProgramData\chocolatey\bin` (the actual tools are located in `C:\ProgramData\chocolatey\lib\rust-ms\tools\bin`; the ones in `chocolatey\bin` are just [shim exes](https://chocolatey.org/docs/features-shim) that call the real thing) - `rustc --print sysroot` prints out `C:\ProgramData\chocolatey\lib\rust-ms\tools`, and I’m able to compile stuff by just calling cargo from powershell like normal. - The standard library is in `C:\ProgramData\chocolatey\lib\rust-ms\tools\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-70cd3b3ea9022c57.rlib` (which should be the right place, since I’m able to compile normally with `cargo`, and it’s within the sysroot) - When I create a new project, the `Toolchain location` is filled in, but the `Standard library` field defaults to blank, and when I try to go ahead anyway, it complains about how there’s `no explicit stdlib or rustup found` So my first question is what exactly I should put in the `Standard library` field (I tried `C:\ProgramData\chocolatey\lib\rust-ms\tools\lib\rustlib\x86_64-pc-windows-msvc\` and `C:\ProgramData\chocolatey\lib\rust-ms\tools\lib\rustlib\x86_64-pc-windows-msvc\lib\`, but neither one worked). Second question is how to get IntelliJ to find it automatically. That’s even more important than getting it to find the source code (there’s only one version of the standard library on my machine, so it should just use that one). Random guess is that it’s looking for, and not finding, the standard library in `C:\ProgramData\chocolatey\lib\`? ---
**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\ **Post date:** [May 2, 2019, 7:23am UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/11 "2019-05-02T07:23:55Z")
I've looked close and indeed a minor fix is required to make IntelliJ look for stdlib in sysroot even without rustup: > > > See > > https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9…890/6 > The standard library is You need **sources** of the standard library and not the rlib ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [May 2, 2019, 1:35pm UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/12 "2019-05-02T13:35:12Z")
> [@matklad](#): > > You need **sources** of the standard library and not the rlib I ... Oh, that `Standard library` field there was for the sources, and it's already just going to let rustc find the rlib. Okay. ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [May 9, 2019, 12:39am UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/13 "2019-05-09T00:39:18Z")
In any case, the sources are going in `C:\ProgramData\chocolatey\lib\rust-ms\tools\lib\rustlib\src\rust\src\` ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [August 7, 2019, 12:39am UTC](https://internals.rust-lang.org/t/new-style-chocolatey-packages-windows/9890/14 "2019-08-07T00:39:21Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.