publishing a crate that depends on itself as a dev dependency

[mockersf]

Problem

It used to be possible to publish a crate that depends upon itself as a dev dependency:

[package]
name = "my_crate"
version = "0.1.1"
edition = "2021"

[dependencies]

[dev-dependencies]
my_crate = { path = ".", version = "0.1.1", features = ["feature-for-test"] }

[features]
default = []
feature-for-test = []

This pattern is useful when you have a feature that you want to enable for tests

This worked on January 3rd, see the dev dependencies of https://crates.io/crates/bevy_math/0.15.1/dependencies published with cargo 1.83

This failed today with cargo 1.84.1

    Updating crates.io index
   Packaging bevy_math v0.15.2 (crates/bevy_math)
    Updating crates.io index
error: failed to prepare local package for uploading

Caused by:
  failed to select a version for the requirement `bevy_math = "^0.15.2"`
  candidate versions found which didn't match: 0.15.1, 0.15.0, 0.15.0-rc.3, ...
  location searched: crates.io index
  required by package `bevy_math v0.15.2 (crates/bevy_math)`

Steps

1. have a crate that depends on itself as a dev dependency
2. publish it

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.84.1 (66221abde 2024-11-19)
release: 1.84.1
commit-hash: 66221abdeca2002d318fde6efff516aab091df0e
commit-date: 2024-11-19
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.1.0 [64-bit]

[epage]

In 1.84, we always include a lockfile, rather than trying to detect when it would be relevant like we did before. When we create a .crate, we strip paths from dependencies. So when we create the lockfile, we then look to the registry for this package but its not there, giving this error.

Before, were you using --no-verify? I assume the verify step would create a lockfile which would have failed.

[epage]

Another case affected by lockfiles is #15059

[mockersf]

Before, were you using --no-verify? I assume the verify step would create a lockfile which would have failed.

Yup, forgot about that but our publish script use cargo publish --no-verify --allow-dirty

[mockersf]

So when we create the lockfile, we then look to the registry for this package but its not there, giving this error.

Could this be bypassed for dev-dependencies when using --no-verify?

[weihanglo]

It has nothing to do with publish verification. It is about cargo publish/package now unconditionally generate a lock file.

For your case, could you try removing the version field? dev-dependency without a version will be pruned during publish. I guess it'll help you get through.

[mockersf]

I tried removing the version and packaging the crate. it means the tests in the resulting packaged crate don't compile as they were written expecting the feature to be enabled. We could feature gate the tests

[epage]

Testing of .crates also came up in #4242 which has the same solution.

From #4242 (comment)

If its on github, crater will still test it, right?

As I said, cargo add makes packages unworkable with crater. We also have people trying to reduce package size by removing test related content, see BurntSushi/bstr#200

I also don't know if relying on --no-verify for this is guaranteed to work either from cargo or crates.io.

Note that there are other problems with depending on yourself (for some reason not finding the issue atm). iirc In some cases, you can depend on a second copy of your library instead of the main copy of it.