Make cargo install respect lockfiles by default

[casey]

Rendered

Currently, cargo install does not respect lockfiles by default, which causes breakages when dependencies release breaking but semver-compatible versions. This RFC proposes to change cargo install to respect lockfiles by default.

There's been a lot of discussion on rust-lang/cargo#7169 without much progress, so I thought it would be productive to open an RFC proposing changing the default behavior of cargo install to respect lockfiles by default, to provide a concrete proposal that can be discussed.

Even if this RFC is ultimately rejected, it will provide some forward progress on the issue, since we can then focus on an alternative to changing the default behavior.

[epage]

There's been a lot of discussion on rust-lang/cargo#7169 without much progress, so I thought it would be productive to open an RFC proposing changing the default behavior of cargo install to respect lockfiles by default, to provide a concrete proposal that can be discussed.

An RFC isn't the best tool to jumpstart progress but instead engaging with the issue is. If there is enough to move forward, i then recommend using Internals wxth a Pre-RFC as a sounding board to help flesh it out.

For myself, i felt this misses a lot of the nuance for why things are the way they are. Without a clear understanding of the problem, you can't talk much on possible solutions. Personally i would recommend closing this while that is iterated on and then going through the process i mentioned. I expect the conversations would then be much more productive, The caveat ill give is the Cargo team just went through a very contentious RFC and i at least am wanting to rebuild my energy before helping mentor the design of this. I can't speak for the others.

[casey]

An RFC isn't the best tool to jumpstart progress but instead engaging with the issue is. If there is enough to move forward, i then recommend using Internals wxth a Pre-RFC as a sounding board to help flesh it out.

I definitely understand the sentiment. My thought here is that the issue has been known and talked about for a long time, without seeing much progress. Even rejecting this RFC would be beneficial, since I think a lot of people would like the return of the pre-1.37 behavior of respecting lockfiles, and if that's off the table, the conversation can move forward productively to think about alternatives.

For myself, i felt this misses a lot of the nuance for why things are the way they are. Without a clear understanding of the problem, you can't talk much on possible solutions.

I think I touched on this with:

Currently, when running cargo install, the latest semver-compatible versions
of dependencies will be selected. This can be beneficial if these versions have
bugfixes.

Is there something else I'm missing? I checked out the original PR, and only saw picking up bugfixes and new features as the reason to ignore lockfiles.

Personally i would recommend closing this while that is iterated on and then going through the process i mentioned. I expect the conversations would then be much more productive, The caveat ill give is the Cargo team just went through a very contentious RFC and i at least am wanting to rebuild my energy before helping mentor the design of this. I can't speak for the others.

I'm definitely happy to close this, I don't feel too attached to this PR. However, there has been a lot of discussion in rust-lang/cargo#7169, and my personal read of the discussion there is that many users would prefer that cargo install respect lockfiles, and that at least proposing to do that with an RFC is reasonable. I think I understand the tradeoffs involved, and I personally think that they are in favor of respecting lockfiles, and I'm not sure that much more discussion would help.

[Aloso]

Even rejecting this RFC would be beneficial, since I think a lot of people would like the return of the pre-1.37 behavior of respecting lockfiles

From what I can tell, the behavior didn't change in 1.37. From the linked issue:

Ah, yea, in that sense there is no change in behavior. I mis-remembered how it used to work. The present stable behavior for install --path is that Cargo.lock is ignored by default, and --locked can be used to honor it. That hasn't changed. (What did change is installing from a registry, which didn't support lock files at all.)

[casey]

From what I can tell, the behavior didn't change in 1.37. From the linked issue:

I believe the change in behavior was to cargo install <CRATE_NAME>, i.e., installing from crates.io.

[KirilMihaylov]

Correct me if I am mistaken, but isn't that why the --locked exists in the first place? If this becomes the default behavior, then a new flag has to be introduced specifying that it should update the dependencies.

This could be potentially harmful if you try installing a package that hasn't updated its dependencies yet, while there is a wild CVE going on, e.g. one of the TLS crates.

[BurntSushi]

since I think a lot of people would like the return of the pre-1.37 behavior of respecting lockfiles

My memory is that this was never the case. cargo install binary-crate-from-crates.io never respected lock files. Could you say where you got the idea that it used to respect lock files from?

EDIT: With hands on keyboard and some digging, yes, cargo install bin never respected lock files. In particular, there was a time when Cargo.lock wasn't even published with the package to crates.io. See rust-lang/cargo#2263. And the fact that cargo install bin doesn't use a lock file by default has been biting me for a long time.

[epage]

I definitely understand the sentiment. My thought here is that the issue has been known and talked about for a long time, without seeing much progress.

While the problem has been talked about for a while, not all of that has been productive and there is more productive conversation to be had. If nothing else, a summary of the state of the thread would be a big help.

Even rejecting this RFC would be beneficial, since I think a lot of people would like the return of the pre-1.37 behavior of respecting lockfiles, and if that's off the table, the conversation can move forward productively to think about alternatives.

In my mind, this RFC does not produce a good platform for us to outright reject. If I were to make a formal proposal to the cargo team for this, it would be to postpone this RFC rather than reject it.

Is there something else I'm missing?

Yes but, as I said, I'm staying out of this. You will either need to find another mentor or take on yourself a lot more of the burden to move this forward.

However, there has been a lot of discussion in rust-lang/cargo#7169, and my personal read of the discussion there is that many users would prefer that cargo install respect lockfiles, and that at least proposing to do that with an RFC is reasonable

rust-lang/cargo#2644 is our most upvoted and commented on issue and people would have likely said the same thing. With a gentle nudge, someone dug into it more and found there were fundamental problems with what "many users would prefer". While there are differences with this situation, I hope this clarifies that that isn't a metric of its own to base designs decisions off of.

[epage]

@rfcbot postpone

While there are reasons we should reconsider cargo installs behavior, there is more fundamental design work that is needed, the author hasn't picked up this design work and I at least don't have time to drive this for them, and I'm not even sure this is to the level of needing an RFC (see cargo's process). As such, I propose we close this in favor of design work continuing on the Issue. At minimum, it would help if someone could summarize the thread. That will make it easier to see the design issues that need to be worked out. If you want a wider audience in brainstorming ideas, you could check with internals.

[rfcbot]

Team member @epage has proposed to postpone this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[olson-dan]

A less strict version of this idea is to enable --locked by default when --version is specified. This is necessary whenever building against an older rustc. Because many maintainers in the crate ecosystem do not consider bumping MSRV a breaking change requiring an appropriate semver bump, it is nearly impossible for any non-trivial project to correctly build against an old rustc without passing the --locked flag. (Edit: to be clear, building against an older version of the crate using --version is happening in this case because of MSRV as well.)

This could be fixed in two ways, either by cargo respecting MSRV when resolving dependencies or by defaulting cargo install to use the lockfile for older versions. Both of these things were probably overlooked because they only seem to come up in the situation of attempting to build against an older rustc without a lockfile.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to postpone, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This is now postponed.