`cargo publish` of a `[lib]` fails when dependencies exist newer than my toolchain version

[epage]

Problem

Captured from https://internals.rust-lang.org/t/pre-rfc-msrv-aware-resolver/19871/65?u=epage

I had a very unpleasant experience:

I work on old version of Rust, usually I develop my library with dependencies by:

cargo +nightly -Z minimal-versions update

But when I publish my library by cargo publish, I got:

Caused by:
 package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.65.0

Is there cargo publish update dependencies by -Z minimal-versions, or it's best to update the dependent version based on the rust-version.

Proposed Solution

No response

Notes

No response

[epage]

We talked about this in today's team meeting.

Though we changed out guidance on committing Cargo.lock based on crate kind (bin/lib), we still choose whether to include the Cargo.lock based on if its a bin or example. Without the Cargo.lock being included, we generate a new one with the verify step which uses the latest dependencies.

We have rust-lang/rfcs#3537 but that excludes "ephemeral" workspaces which is targeted at cargo install but I believe it also applies to cargo publish (need to verify that).

Options

• Recognize this is an exception case and tell people to upgrade or run with --no-verify
• Include Cargo.lock as a statement of what was verified, fixing this is a side effect
  • Mostly meaningless but doesn't take up much space
• Prefer verifying with existing lockfile
• Prefer verifying with latest and tell the user to upgrade (ie "do dev on latest even if you support older")
• Prefer verifying with latest but allow overriding with MSRV aware resolver
• Extend the MSRV-aware resolver RFC change to cargo publish (which we'll need to distinguish from cargo install as they are both ephemeral)

I think someone expressed that cargo publish could map to what cargo install does which the MSRV RFC defers out.

ehuss pointed out that the verify step using the latest dependencies, rather than your lockfile, was very intentional to ensure you verified what your dependents are going to run.

As the main point of discussion was whether to include this in the RFC or if we could do a quick fix, we decided to shift the conversation to this issue.

[epage]

ehuss pointed out that the verify step using the latest dependencies, rather than your lockfile, was very intentional to ensure you verified what your dependents are going to run.

With an MSRV-aware resolver, we will move from dependents using "latest" (all dependent on what was already in their lockfile) to multiple points within their version timeline. For myself, the earlier points in that timeline are what are more likely to break you then the later points.

For myself, I feel like most cargo publish verification is too late and should be a very loose safety catch. Currently, we don't support packaging and then publishing a workspace, so packaging errors in a cargo publish step puts you in an awkward state. Even if we have workspace support, your release process usually includes other steps like updating changelogs and versions, etc that need to be undone.

[Nemo157]

the verify step using the latest dependencies, rather than your lockfile, was very intentional to ensure you verified what your dependents are going to run.

This isn't the current behavior, if you have a crate where the lockfile is included in the published package, that lockfile will be used during the verify step.

[epage]

With #14815, I think this can be closed.