declare version of windows-sys by range set to fix compile under win7

[Fenex]

Declaration with range is a recommended way to add windows-sys crate as dependency:

Using a range instead of the default Caret requirements helps avoid duplicate versions in downstream graphs and improves resolver flexibility.

Additionally, [email protected]+ has a bug that causes compilation errors under *-win7-windows-* targets, so this change will allow your users to choose & lock older version of windows-sys in theirs Cargo.lock to avoid this bug and continue support Windows 7.

I faced with compile errors causes from [email protected] (0.5.11 works fine).

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Fenex]

Sorry, I forgot to rebase before. I fix this.

[epage]

I'm not a fan of multi-major semver versions when we are not testing them to make sure the our version requirement is valid.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Fenex]

I'm not a fan of multi-major semver versions when we are not testing them to make sure the our version requirement is valid.

I start facing with compile errors in various projects that declare home@^0.5.12 as their dependency. What can we do?
Microsoft maintainers of windows-sys refuse a PR to fix their bug.

Maybe it is possible to make a downgrade windows-sys to 0.60.2, at least until we actually need some features in new versions of windows-sys?

[Fenex]

Maybe it is possible to make a downgrade windows-sys to 0.60.2?

Rust ecosystem has perfect support Winows 7, exclude this [email protected]+. Even Rust 1.91.1 can be compiled (without any changes in source code (!) ) to running toolchain with host tools on Windows 7: rust-lang/rust#148362

[epage]

I start facing with compile errors in various projects that declare home@^0.5.12 as their dependency. What can we do?

Either you can switch to std::env::home_dir, or you either get it indirectly or can't use home because the MSRV is too high and you should use cargo update home --precise <ver> to lock to an older version of the package. I recommend against pinning in your Cargo.toml as that affects everyone, even those who don't care about Windows 7 support and can cause incompatibilities between packages.

[Fenex]

Either you can switch to std::env::home_dir, or you either get it indirectly or can't use home because the MSRV is too high

I guess you misunderstand me. MSRV cannot be too high for me, because I use the latest rustc 1.91.1 for compiling.

You give me advises for case if I write my own crate. In this case I really can make all versions under control. However if I want to compile not my program (for example, running cargo install sea-orm-cli), First I need to clone source code, then take many update --precise steps. I believe, in the soon future, I also need to take a new difficult step: "patch source codes". And this step will include not only patching source code of the program, but also its dependency that cannot be precised from certain version.

Well, I understood you and your mood about this problem. However this is a really sad to see how the whole ecosystem is crashing, even on tier 3 target.

[epage]

So if this is for cargo install, then you still run into the issue of having to patch all of the packages to use the old windows-sys unless you can get them all to accept patches to lock to an old version.

[Fenex]

So if this is for cargo install

This is not only for cargo install, but for general use Rust on Windows 7.

, then you still run into the issue of having to patch all of the packages to use the old windows-sys unless you can get them all to accept patches to lock to an old version.
Yeah, sad true.

For now, not many crates that required [email protected]+, home is one of them. But yeah, count of crates will grow in time.

Well, I'm trying to figure out how resolve this problem with minimal effort.

Hmm. If I create my own windows-sys-legacy with exactly all windows-sys' version list, is it possible to use cargo.patch \ cargo.replace directives in my Cargo.toml to make replace windows-sys in all tree subcrates?

[epage]

We discussed this in today's Cargo team meeting.

Some potentially relevant sections from tier 3 policy

Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

While there would be a clearer line if we were using new features from windows-sys, we felt that upgrades for staying on the latest versions are a sufficient motivation for our negatively impacting host tools support on a Tier 3 target.

Declaration with range is a recommended way to add windows-sys crate as dependency:

There was some concern within the team over them recommending this

• As mentioned already, there is a testing burden associated with this
• There are unexpected behaviors in the dependency resolver when it comes to multi-major version ranges, including versions changing in Cargo.lock on unrelated dependency changes.

Ideally, they would not bump their major version so much which would provide more flexibility in how all of this is handled.

As such, I'm going to go ahead and close this.

[roblabla]

FWIW, Microsoft is uninterested in merging win7-related fixes into windows-rs: microsoft/windows-rs#3791. I'm currently working around this by using a fork of windows-rs in my personal builds, but it's a bit unclear on how to progress here for more general availability of the Win7 target. There's a workaround provided by riverar for that specific issue in the PR, but I'm not sure if it's something that we can bundle in the toolchain easily (it requires shipping a .def file, and passing it as a linker flag).