release cargo test helper crate to crates-io

[drahnr]

The cargo test helper crate would be a very much appreciated relief for all cargo-$tool plugins, mostly speaking for cargo-unleash and cargo-spellcheck .

(This didn't seem to match any category, hence the free form issue).

[Eh2406]

Do you mean the cargo-test-support or cargo-test-macro crates? They seam pretty customized to our needs. I would love to see how they could be used for your projects. They should be available as git dependencies. Would you be willing to try using them as git dependencies and link us a PR to show how it works for you?

If they turn out to be useful we would still have to agree to what the stability guarantee is. Updating and publishing another set of crates is a nontrivial amount of work. For Cargo's Rust API, we release a new and incompatible version of the library every six weeks. For other crates we put in the effort to track when breaking changes actually occur. So what the release cadence is will need to be figured out.

[alexcrichton]

For now these crates are not raelly intended for wider consumption. You're welcome, as with all open source, to fork it and customize it for your needs as well. Otherwise though I don't think we want to manage publication of these crates on crates.io.

[Fabian-Gruenbichler]

would it be possible to re-visit this with a slightly different rationale?

over in the Debian packaging ecosystem, cargo is actually packaged twice:

• one source package cargo for the binary cargo
• one source package rust-cargo for the library cargo

the former uses the source tarball published upstream and vendors all the dependencies (with some scripts to remove stuff that is not needed for the purpose of packaging cargo the tool for Debian usage), to avoid the bootstrap cycle of cargo requiring various crates that in turn also require cargo to build. this is basically an excemption that cargo as toolchain package has from the general Debian rule of "no vendoring/code copies". as part of this build, the cargo testsuite is executed.

the latter uses the same tooling as all regular crates packaged for Debian - obtain the source from crates.io, transform Cargo.toml into Debian package and CI metadata, etc.pp.. there are some other crates (most notable, the crate responsible for this transformation, which is called debcargo) which are packaged that use and depend on cargo the library. right now as part of the packaging of rust-cargo, only a regular build is done, since the needed dependencies for running the testsuite are not published on crates.io and thus not packaged for Debian. for the sake of these reverse dependencies, we'd like to run the testsuite not just for src:cargo, but also for src:rust-cargo to catch any regression caused by patches (most commonly, relaxing/upgrading dependencies) on our side.

would it be possible to re-consider publishing cargo-test-support and cargo-test-macro (with the same "eternally-unstable" version number as cargo the lib crate itself)? I know this is a pretty niche use case, but IMHO it's a valid one nevertheless..

[epage]

Personally, I think this is worth us reconsidering.

As a cargo team member, I find it frustrating that we do not publish this as it'd be a big help for me for browsing the documentation (I tend to prefer docs.rs over cargo doc --open).

I also have a couple of tools now (cargo-edit, cargo-release) that are using it via a git dependency.

[Fabian-Gruenbichler]

are there any blockers for this?

[weihanglo]

As a cargo team member, I find it frustrating that we do not publish this as it'd be a big help for me for browsing the documentation (I tend to prefer docs.rs over cargo doc --open).

The doc we currently have is on https://doc.rust-lang.org/nightly/nightly-rustc/cargo_test_support/index.html.

For other crates we put in the effort to track when breaking changes actually occur. So what the release cadence is will need to be figured out.

Speaking of publishing this to crates.io. Cargo the project has gained a better support of managing member packages since last year (kudos to cargo-semver-checks and workspace-inheritance feature 😃). I am on the side that we can just publish those two crates with minimal efforts. Yet, the API is not and may never be stable.

[PaulDance]

I also have a couple of tools now (cargo-edit, cargo-release) that are using it via a git dependency.

Same for me, although only one. Having it published would be more comfortable, for sure. It would also help in circumventing #10752 specifically for these packages.

Yet, the API is not and may never be stable.

That should be just fine in my specific case.

[weihanglo]

Some considerations before publishing them:

• Naming — Are we good with cargo-test-*? Should we follow the new naming rule cargo-util-something?
• Setting the expectation — We are not going to accept major features for these two crates, unless it also helps clean-up Cargo its own testsuite (in a meaningful sense not cosmetic changes). We should document this somewhere.
• Stability guarantee — No guarantee on any stability across versions. We would try our best to maintain SemVer compatibility. For behavior changes, we don't want to pay too much attention to it. For example, this might only require a patch version bump but could break people's test code.