Publish to crates.io

[stefnotch]

It'd be lovely if this tool were published to crates.io, like the majority of Rust tools.

Then the installation instructions might be simpler for users who already have Rust.

[RyanGlScott]

I agree. One reason that we haven't yet uploaded mir-json to crates.io is that any given mir-json release would only be buildable with a particular rustc nightly, and I could imagine lots of bug reports from confused users who try to install mir-json with an unsupported rustc version. That being said, we could include a rust-toolchain.toml file to ensure that when a user runs cargo install mir-json, cargo will download the correct nightly before attempting to build the tool.

[RyanGlScott]

Actually, I'm not sure if rust-toolchain.toml takes effect with cargo install or not. It would take effect if you cloned the mir-json repo and built it from source, which would simplify the current story slightly (in that you wouldn't need to manually change your Rust toolchain before building).

[stefnotch]

Ah, I see. I suppose a stable mir format would be needed for it to work with multiple rustc versions.

I personally would love anything that simplifies the installation instructions. Even getting rid of a single step is frequently worth it, in my opinion.

[RyanGlScott]

Ah, it turns out that we already have a rust-toolchain.toml file:

mir-json/rust-toolchain.toml

Lines 1 to 2 in 3b53858

	[toolchain]
	channel = "nightly-2023-01-23"

I think that we need to add components = ["rustc-dev"] as well, but most of the ingredients are there.

Another thought that popped into my mind: there are several commands inside of mir-json that spawn rustc subprocesses. If a user installs mir-json with one rustc version (the intended version) but later changes their toolchain to have a different rustc version as the default, will mir-json's rustc subprocesses still pick the intended version? Surprisingly, some experimentation suggests that the answer is "yes". I'm not sure how that works exactly, but that is a fortunate coincidence.

[spernsteiner]

If a user installs mir-json with one rustc version (the intended version) but later changes their toolchain to have a different rustc version as the default, will mir-json's rustc subprocesses still pick the intended version? Surprisingly, some experimentation suggests that the answer is "yes".

I suspect this only works in certain cases. The various mir-json binaries link against a specific version of the rustc libraries and will always behave like the nightly they're built against. But we might run into trouble when invoking normal rustc instead of mir-json or one of our other binaries. In particular, using cargo crux-test in a project that uses proc macros might compile the proc macros with the default toolchain and produce proc macro crates that can't be loaded by mir-json.

We could probably fix this by setting RUSTUP_TOOLCHAIN or passing +nightly-xxx args in more places.

[RyanGlScott]

But we might run into trouble when invoking normal rustc instead of mir-json or one of our other binaries.

To be clear, this is the scenario I was referring to in my comment in #48 (comment). Somehow, every rustc invocation that mir-json uses managed to pick the right rustc version when I tried it, even when a different rustc was selected as the default toolchain. This might have simply been a lucky fluke, however. I agree that we should be using RUSTUP_TOOLCHAIN/+nightly-xxx to make this more foolproof.