Publish Without an Optional Git Dependency

[dcampbell24]

Problem

I know that git dependencies cause problems for publishing a crate, but what if the git dependency is optional and not included in the release of the crate? Then you ought to be able to publish the crate.

Proposed Solution

If the only git dependencies are optional and not included when publishing the crate allow publishing the crate.

Notes

No response

[dcampbell24]

You can currently delete the optional dependency, run cargo publish --allow-dirty to force publishing the crate, then run git reset --hard.

[epage]

You can currently delete the optional dependency, run cargo publish --allow-dirty to force publishing the crate, then run git reset --hard.

Before 1.81, this would cause Cargo to not include .cargo_vcs_info.json which would make it a lot more difficult to audit what changes were made during the publish process.

[epage]

Currently, Cargo will strip dev-dependencies that only have a path (no version) on cargo package, cargo publish. This allows for publishing packages with a cycle (#4242).

It sounds like you are suggesting we strip git dependencies that have optional = true set.

If there isn't a feature that references the dependency

• We have proposed removing support for this in a future edition (see RFC 3491)
• We won't know about the features name for --check-cfg but then again those lints won't show up because of --cap-lints

If there is a feature that references the dependency, what do we do with it? Remove those references which could easily lead to broken code? Remove the feature? If we had rust-lang/rfcs#3487, then we could limit this to private features and strip those.

In either case, if there isn't a restriction like limiting this to private features, there is the problem of people doing this on accident, possibly even accidentally removing and adding features as they make changes.

[dcampbell24]

Hmm... I should add that the optional dependency is not used in a library. It is only used in a binary with required-features = ["feature"] being set. With a library it makes sense that it has to be private, but in a binary only it should not have to be. If it is only used in the binary we should be able to remove the binary from cargo publish.

How do we know it is only intended for the binary and not an optional dependency of the library? We could add a flag like required-feature = true. Then it is only added where it is a required feature.

I should note that in my use case I have a library and many binaries in the same crate.

[epage]

That way to tell if the feature is only for a bin feels unclear and fairly specialized.

Is there a reason you don't split out into multiple packages? That seems like the natural way to solve this problem.

[dcampbell24]

Maybe, I should.

[dcampbell24]

I worked around the issue by making the binary an example and the git dependency a dev-dependency.