microsoft
Consider pinning specific nightly version
As of #97, this project now declares its need for a nightly compiler version, which helps with compiling the project normally. However, right now, it will cause rustup to use whatever nightly version happens to be selected by the user recently.
For consistency, and for reproducibility, the project should ideally pin a specific nightly version that is known-good and working, and pin that. An example of a project that does this is Polars.
This would also allow downstream distributions to verify package reproducibility, as the compiler binary will be stable over time.
For transparency: I am the package maintainer for this project at Arch Linux.
Thank you for making the Arch package! I've been using it on my systems already. 😅 If you have any additional input on https://github.com/microsoft/edit/discussions/341, I would also greatly appreciate it.
How urgent do you consider this? The project pretty much only depends on the let_chain feature which I expect to be available in stable Rust 1.88 (= 2025-06-26). We could just migrate to stable Rust afterward, by writing our own Vec in place of allocator_api.
I'm saying this, as I'm not particularly eager to do monthly "chore" PRs to upgrade the toolchain version for the indefinite future.
Thanks for the response. To answer your questions
If you have any additional input on https://github.com/microsoft/edit/discussions/341, I would also greatly appreciate it.
The main thing is that it shouldn't be edit, at least not for Arch Linux. We lack an alternatives system, like Debian-based distros do, so binaries simply cannot collide. The alternative is to make this package collide with vi, but seeing as that's installed on roughly half of all Arch linux machines (source) that will cause more trouble.
How urgent do you consider this?
Not urgent at all, I've labeled my own tracking issue as low priority and lowest severity. It got flagged to me by another contributor who was looking into recent reproducible build failures. If you're aiming for 1.88, that's plenty good enough of a time line.
It appears that the current trend is towards msedit as opposed to ms-edit. Is there an option to rename the package in Arch's repository?
FWIW, Microsoft's internal Rust compiler team, presumably closely aligned with the open-source Rust team, gave us the official recommendation to use RUSTC_BOOTSTRAP=1 for building this project with a stable compiler. We use that for building the official Windows binaries and plan to continue using it for the foreseeable future for the build-std feature.
If you're aiming for 1.88, that's plenty good enough of a time line.
Good to hear! Should be possible to achieve.
It appears that the current trend is towards
mseditas opposed toms-edit. Is there an option to rename the package in Arch's repository?
I have no strong opinions on the matter, if this is the ultimate decision I'll probably follow, especially if the project decides to build itself as such.
FWIW, Microsoft's internal Rust compiler team, presumably closely aligned with the open-source Rust team, gave us the official recommendation to use
RUSTC_BOOTSTRAP=1for building this project with a stable compiler.
That seems to contradict public statements by the documentation, the rust team, and some informal complaining I've been privy to over the years. To quote the compiler dev documentation:
The build system sets
RUSTC_BOOTSTRAP=1. This special variable means to break the stability guarantees of Rust: allowing use of#![feature(...)]with a compiler that's not nightly. SettingRUSTC_BOOTSTRAP=1should never be used except when bootstrapping the compiler.
I'm aware some people use it to get around "stable only" restrictions in the packaging system, but Arch doesn't have those, so nightly will do.
How urgent do you consider this? The project pretty much only depends on the
let_chainfeature which I expect to be available in stable Rust 1.88 (= 2025-06-26). We could just migrate to stable Rust afterward, by writing our ownVecin place ofallocator_api.I'm saying this, as I'm not particularly eager to do monthly "chore" PRs to upgrade the toolchain version for the indefinite future.
For Fedora, I would appreciate Microsoft Edit to migrating to stable Rust and not requiring weird stuff to build it.
FWIW, Microsoft's internal Rust compiler team, presumably closely aligned with the open-source Rust team, gave us the official recommendation to use
RUSTC_BOOTSTRAP=1for building this project with a stable compiler. We use that for building the official Windows binaries and plan to continue using it for the foreseeable future for thebuild-stdfeature.
Hi, the official policy can be found in https://doc.rust-lang.org/beta/unstable-book/compiler-environment-variables/RUSTC_BOOTSTRAP.html, which was only recently explicitly stated^mcp to help clarify the stability policy surrounding the use of RUSTC_BOOTSTRAP, but it was always an perma-unstable "feature" (or mechanism, if you will), intended only for bootstrapping. In particular, note that though you may choose to use RUSTC_BOOTSTRAP to bypass stability gating, doing so necessarily opts you out of the normal stability/backwards compatibility guarantee of stable.
Despite being usable on stable, this is an unstable feature. Like any other unstable feature, we reserve the right to change or remove this feature in the future, as well as any other unstable feature that it enables. Using this feature opts you out of the normal stability/backwards compatibility guarantee of stable.
It might be helpful to propagate that stability opt-out caveat in the docs.
I'll close this issue for now since we already have #44. We'll add custom Vec/String types and build on stable 1.88.
Arch has cargo test --frozen at packaging process. Is it not enough to believe RUSTC_BOOTSTRAP=1?
No, those two things are unrelated. --frozen is related to downloading packages (essentially pinning them to the specified version) and RUSTC_BOOTSTRAP is about nightly Rust.