New-Style Chocolatey Packages [windows]

tools and infrastructure
1

Prompted by Maturing installation options 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, 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, 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 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,

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).
3 Likes
2

CC @kornel, who opened the original topic, and @retep998, who is heavily involved in Rust on Windows.

3

Is there plan to change default to msvc?

4

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.

3 Likes
5

Thank you for explantion about your plan. It sounds great! I have another question. Do you have plan to provide rustup on chocolatey?

1 Like
6

Somebody else already did that. 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.

7

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.

8

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.

9

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.

1 Like
10

@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 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\?

11

I've looked close and indeed a minor fix is required to make IntelliJ look for stdlib in sysroot even without rustup:

The standard library is

You need sources of the standard library and not the rlib

12

I ... Oh, that Standard library field there was for the sources, and it's already just going to let rustc find the rlib. Okay.

13

In any case, the sources are going in C:\ProgramData\chocolatey\lib\rust-ms\tools\lib\rustlib\src\rust\src\

14

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