unicode-normalization v0.1.10 bumped smallvec to 1, breaking builds with rustc < 1.36 #50
Comments
|
Not all crates guarantee MSRV as part of their stable API. Please pin the dependency if you need to . |
|
I feel like unicode crates are quite important and should guarantee MSRV. Is this up for discussion? |
|
Oh, it has been discussed already, ok. |
|
The more important the crate is the more churn a breaking change causes. It's a two edged sword, guaranteeing MSRV is not an obvious choice. |
Thanks for the hint, I will do that for future releases. However, I cannot do that for past releases. Because we depend on a library that is not installed in the docs.rs build environment, we do build and host our documentation ourselves. So now to build the documentation for every release we made so far, our solution has to So yeah, we can handle that, but it is a hassle. |
|
Alternately you could include a Cargo.lock file in your library repo. I know the official docs say this is not useful for libraries, but in specific cases, like pinning to old Rust toolchains and corresponding dependencies, it is very useful. |
|
While it's hard to manage MSRV, it'd be valuable for crates as potentially core as this one to try their best to not require beyond 1.34.2 without a breaking change in their semver. Debian (and potentially other OSes derived from it) ship 1.34.2 in their stable release currently and yes it's a difficult job but maintaining buildability on that platform is valuable for our users. This is actually a core part of my inclusivity message for Rust 2020. |
We do have the Cargo.lock checked in, and this doesn't seem to help. Edit: Thinking more about this, I think you are right, this should and probably does help. However, our early releases do not contain the Cargo.lock. Which brings me back to my original problem: What should I do about prior releases? |
|
@kinnison the problem is, ultimately, doing breaking changes on MSRV requires everyone else in the ecosystem to do piecewise upgrades, when it comes to core crates like this one. it's a tradeoff, and i rarely see the other side of that tradeoff acknowledged. It's a lot of work, and I'd be happy to make this a major semver bump and yank the old version if someone was willing to put in the effort of getting all of these crates (and their reverse dependencies, etc) upgraded. I cover this a bit here. Ultimately, I'm not interested in doing a ton of labor to support this use case, when there are workarounds available for people with this use case. @teythoon which library is this? |
sequoia-openpgp
That is our workaround, yes. |
|
@teythoon right, you need to pin it to some version in the lockfile, and be careful about updating. |
|
@Manishearth I get that it's a tonne of work, which is why I'm not castigating you (or at least not intending to) -- but I wonder if as a community we need to get better at this. As more traditional distros include Rust in their package sets, it'll only become more important. Just thought I'd speak up as I'm friends with the sequoia people and appreciate their pain because we're trying to ensure it's packagable for Debian, and I see the pain from both sides so hopefully don't just come across as a whiny distroboi :D Perhaps if the rust project offered MSRV checking github actions that might be a nice way to make life easier for developers? I have no idea how hard that'd be. |
|
I don't think this is a problem that can be solved by community efforts. I think putting this burden on crate maintainers is a mistake, the tradeoff still exists and everyone has to deal with it. We already check MSRV in CI for this crate, that was not the problem here. There is a very specific tooling improvement that solves this problem:
The first one is already an accepted RFC and just needs to be implemented. The second one can happen once the first one starts spreading. Asking crates to major bump on an MSRV change is, at best, a hack, working around the fact that crate resolution isn't smart enough yet. If we can fix crate resolution, this hack isn't necessary. |
|
I see two problems. First, Debian users are going to install rust and then discover that it cannot build the software they were trying to build. Second, why should a distribution bother to package a compiler that is practically obsolete six months into their two-year release cadence? Both problems reflect poorly on Rust and its community. FWIW, I do agree that this seems to be a tooling problem. However, in this very instance, if #46 (comment) is true, then I feel like you are creating a problem without any actual benefit. |
This is what lockfiles are for. Use them when packaging. This is a solved problem, the unsolved bit is that it's hard to upgrade dependencies keeping an MSRV in mind (and as I linked above, there are features that should be implemented that fix this). Given the kind of stability debian packages need, you'd need to package crates with lockfiles anyway. There's no getting around that. As for debian users attempting to compile random rust crates and having them fail? That ship sailed long ago (and Rust isn't the only language for which this has happened), major semver bumps on MSRV won't change that. There is always going to be newer code.
That wasn't the only motivation, in general I (and others) wanted to move the ecosystem over. Having multiple copies of a crate in the ecosystem isn't great and tends to cause problems over time.
I'm really tired of engaging with packaging people who demand crate maintainers do extra labor to suit their special needs, especially when ignoring tradeoffs. This isn't the first time it has happened, and I'm tired of it. Turning this into "listen to me or else we'll stop packaging rust" is toxic and childish, and it's not going to work here. |
IME, that's unlikely to happen. Its pretty normal for vendors to hate upstream with a passion and still be carrying their stuff. That's because the role of a vendor is to protect its users from upstream, and anything a vendor can't get fixed upstream gets turned into maintainer self-abuse :) ( And mountains of patches, and believe me when I say vendors maintaining an effective fork of your crate under the same moniker has a lot of downsides ). But a prime reason vendors try to pressure upstream is not because it suits them, but because the collective userbase of all vendors and users benefit. If a given crate author gets tired of vendors complaining about how their dependencies are breaking on old rusts, those crate authors work around the problem by using different crates instead, or forking the code in some way (eg: hand-inlined) to avoid the problem. But the world would be a better place if people didn't need to fork just to avoid this sort of issue. Yes, this is symptomatic somewhat of various inadequacies in the tooling, but crate authors also need to accept those defects and inadequacies are there, and target for them, not target for an idealised programming language ecosystem that doesn't exist yet and users can't use. |
Here's the problem, vendors aren't the only user base here, and that acknowledgement is conspicuously absent from most such debates. There's a tradeoff here. Besides, I already mentioned that lockfiles solve this problem. They don't solve it in an ideal way, but they solve the main problem. If you're packaging a library, use a lockfile. If you're using packaged rust to build a locally cloned library from github (which won't have a lockfile) ... uh, don't do that, we recommend using rustup for local development. But if you have to, you can use |
Absolutely, and I don't honestly know where the line ought to be drawn here. What I do feel is that telling any user-base that they are essentially not interesting to a project is not great from a community inclusivity point of view. Saying "Hi, we acknowledge your needs, but the costs for us to cope with them are too high because X, Y, and Z, but if you're able to help us resolve that, we can help" is more productive. In this instance I think @Manishearth has done his best to suggest ways that tooling needs improvements in order that it's not a strong cost for his team, and there is a distasteful but functional way for @teythoon to anchor a version dependency for now. But eventually some transitive dependency of his will end up needing a newer Independently, people like myself need to be looking at ways to make Rust's preferred model more palateable to users who like the slower more measured approach of the more "traditional" distros. Here's hoping we can all keep discussions like these at least moderately positive, even if they don't resolve things the way issue-filers would hope. Perhaps better documentation for things like |
|
Right, that's why I try to do the work if it's a small amount, but in this case the costs are pretty high, which is why I suggested alternatives. We need someone to implement the MSRV-in-cargo rfc if we really want the tooling to improve here. |
That feature is nightly only, so can't be used by anyone using a stable rust. Which of course, are vendors and probably big companies running rust. |
|
sigh If you're a big company or a vendor, use a lockfile on your codebase. The only time this is a problem is if you're cloning a library directly off github and expecting it to build on an older rust. Which you really shouldn't be doing, use rustup, or use |
- The dependency for unicode-normalization was introduced in
f07a1f4, with the goal (I think)
of keeping a low MSRV. In #413, @nwalfield pointed me to
unicode-rs/unicode-normalization#50,
with more background.
This cleanup is by analogy with the cleanup in !535 -- we are
trying to avoid a higher dependency, but there is no reason to pin
to a specific version; our transitive dependencies can take care
of setting the lower bound on the version.
Signed-off-by: Daniel Kahn Gillmor <[email protected]>
unicode-normalization v0.1.10 bumped smallvec to 1, breaking builds with rustc < 1.36. This breaks the expectations that an update using the "caret requirements" will still compile. This notably impacts everyone using rustc as packaged by Debian stable.
To recover, please revert the version bump of smallvec, and release 0.1.12. A clean transition to smallvec 1 can be done in 0.2.0.
The text was updated successfully, but these errors were encountered: