rust: bump MSRV to 1.76.0 #2462
Conversation
|
It doesn't sound like we gain much from bumping the MSRV. It does make it a little annoying for new users who want to build from source if our MSRV is very recent. I don't remember the details now, but I think I heard from maybe 2 people that the bump to 1.71 was a little annoying for them. What do you think? |
|
Well, I thought we wanted to start bumping the MSRV more regularly now, right? There's little reason to lag so far behind while we're still so "early in the races", so to speak. I feel like if it's annoying to upgrade, we should suss out why; I will be honest, I barely even think about it and just keep on the latest stable compiler in 99% of my apps, because Nix/rustup provision toolchains on demand after bumping a flag. But I think that's actually more of a reason to do regular bumps more often, not a reason to do it less and put it off. |
|
I'm not sure at all that I remember this correctly, but here's what I think I remember:
The second case (if I understood it correctly) seems less important because the cost will probably have to be paid for some project eventually anyway, at least if users install many Rust-based tools. Forcing users to install rustup to install jj seems more unfortunate. Maybe it's enough that we have the pre-built binaries for released versions. Users who want really to install from source can probably install rustup too? |
|
Yes, I think we shouldn't encourage people to install from source, or worry about it. I towed the line on this for a long time in some previous life, where I would say, "just install the package managing tool and install <useful utility XYZ>", but these days it's far too easy to produce binaries for projects quickly, and Rust has great support for it. But compilation from source, even in the best case, is a big support burden in a project in the long tail, and maybe not one you want to bend over backwards for. It's not a bad goal, but one to be tread carefully. The primary place where the source compilation argument comes up is when it comes to integrating with user's package managers. This comes down to a support burden, and ultimately a cultural thing. I don't think we should go out of the way to make life hard here, but I also don't think we should bend over backwards for it right now while there isn't much demand and the iron is still hot, so to speak. If people don't want to install Realistically I don't think we should worry about upstream package managers and concerns like their old rust toolchains, because we are nowhere near a stable 1.0 release or any kind of large userbase. And I might sound biased as a Nix maintainer but, I'll tell you that if Nix didn't package software and updates so aggressively — I wouldn't bend over backwards to support it, either. In fact, as I mentioned passively in #2471, I think the install page should basically be reworked to be significantly shorter and, spoiler, pretty much only advocate people to install binaries directly. Source compilation is best left to the contribution document, mainly. We should instead produce binaries regularly and automatically, both releases and perhaps even nightly builds for users (every commit is a little excessive, perhaps.) I think one of the tricky things here to keep in mind is that, Cargo is pretty OK and easy to use. This has a result where it makes it pretty easy to compile from source, so you may wonder, "Why not have people do that? Why not support it to be nice? Can't be that big of a deal?" Which isn't bad motivation. It certainly keeps you on your toes; you can't do too many wacky, off the beaten path things. If the compilation process was, in contrast, hellishly complicated and distro specific, then we would "of course" tell people to "just use the binary releases" and we would produce them regularly, because the alternative would be fielding tons of support complaints about "I don't have this tool" or "My distro doesn't have that package" or whatever. So I think it's ultimately a support thing. I think it's a case where an alluringly simple procedure actually creates some coincidental complexities and baggage that you have to hold onto. Personally? I think we should just emphasize binary releases up-front and center and leave compile from source issues in a separate category. We may just want to draw some lines there — e.g. for compiling from source we are just going to expect you to have a up to date rust toolchain, or be able to acquire one. Stuff like that. |
|
And just to be clear: we shouldn't make it any harder. |
|
My 2 cents: first, thank you for checking all the clippy issues! However, my feeling is that we could postpone merging this for a few months at least. 1.73 is still very new, and as Martin said, there wasn't anything new and exciting there. (I don't insist on this, though). I agree with Austin's point that it doesn't buy us as much when (Ironically, your careful research is a major reason I think this doesn't seem to buy us much. This is valuable information IMO! ) Once
I think this is reasonable eventually, but not quite yet. It's still pretty common that there is a bugfix or an important new feature that's only available in prerelease. The frequency of this situation seems to be decreasing (and the more consistent release schedule helps), but |
Can you elaborate on this? While I understand (but don't always agree with some) churn arguments, I personally see it as a developer-exclusive "thing", and don't think it has any meaningful impact on anyone's perception, at all. Well, except our own, but I just don't agree it produces an inferior product in any way; it's mostly neither here nor there, actually. Do dependabot updates produce an inferior product when we apply their updates 10+ times a week, even if we don't immediately need 99% of the bugfixes that dependabot gives us? I think I've said this before, but something like 25% of all PRs in this repository were created by dependabot. But we do it anyway. In fact I think MSRV updates should be automatic, too, and automatically applied to the repository with automerge enabled on +1, essentially just like dependabot works now. The compiler is just a dependency like any other, though very important. It needs to be updated regularly, too. I don't deny there can be some minor cuts induced by these sorts of things. Automatic dependency + MSRV updates for example mean your There is another manifest phenomenon I forgot to mention earlier which was (is) very common with Nixpkgs that I see here a little bit — at this exact moment, it's likely a lot of people who are interested in Jujutsu are going to try and write patches for it. Because they probably want it to do something extra it doesn't quite do, like me. In other words, an unusually high proportion of users are also patch contributors. That is not uncommon in the early life of most FOSS projects. So, we should probably not try to make life hell for them; I don't think this kind of stuff does that. But this phenomenon, I suspect, will taper off very quickly as low hanging fruit is picked and the userbase expands, too. Anyway, we can hold off on this. But I really don't see the MSRV bumps as any different than a regular dependabot update. Actually, if it was a dependabot update, would anyone even care? |
Oh, and I've seen this suggestion from you — and I do think this is roughly the right target we should do in the long run. We'll need to be careful about dependencies and all sorts of things, but it's a practical target. Just not right now. |
I don't mean anything major or original, just things similar to what Martin mentioned in #2462 (comment). I'd guess this would mostly benefit people unfamiliar with Rust ecosystem who nevertheless want to use jj's prerelease, or people who try to package In any case, I don't want to overstate my conviction, and I don't think it makes a major difference. All I wanted to say is that it seems we could stay a few months behind the latest Rust release for little cost. If people prefer, I'm also OK with merging this: it would not affect me personally, we'd probably upgrade anyway a little later, and it would take actual effort to find out how many people, if any, it would affect negatively. I do remember being quite resistant to installing Rust via their bash script for the first time. I think this was after a bad experience with the Node ecosystem and, to a lesser extent, Go. I'd have to learn where this ecosystem likes to put its binaries and figure out what I want to do with my PATH, how to update it and how much manual work that takes. So, I'm sympathetic to people who just want to compile a program with a Rust that was packaged by their system, even though I now know that Rust is resistant to being packaged, takes pretty good care of itself and the user, and so it's usually better to just install Rustup. |
This is to get the latest version of `rustc`, which was released this week. Needed for follow up MSRV bump. Signed-off-by: Austin Seipp <[email protected]> Change-Id: I9153ea8f184f9b46a073671f623ef9f63a3f5036
Signed-off-by: Austin Seipp <[email protected]>
thoughtpolice
force-pushed
the
aseipp/push-nryxskwryqxs
branch
from
853ffea to
fef9cf0
Compare
|
This is now blocking some dependabot updates as Clap as bumped its MSRV to 1.74.0; I've gone ahead and pushed us to 1.76.0 which was released this week. (As a side note, it looks like the |
Summary: I was testing 1.72.0, but in order to see if some clippy bugs had been fixed, I bumped it to 1.73.0. The bugs weren't fixed; but I guess we can just bump things here, anyway.
Change-Id: I038346d8a821f83f62cbf122a79c8f30
Checklist
If applicable:
CHANGELOG.md