rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.63k stars 2.4k forks source link

Suppress missing description/repository/etc warnings when publishing to a custom registry #4840

Open sfackler opened 6 years ago

sfackler commented 6 years ago

These fields don't necessarily make as much sense if you're publishing to an internal registry where there isn't the same need for discoverability as there is on crates.io.

stale[bot] commented 6 years ago

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

sfackler commented 6 years ago

Still relevant, needs someone to do it, etc.

dwijnand commented 6 years ago

Is https://github.com/alexcrichton/cargo-local-registry the tool for creating an internal registry to publish to? I'm trying to understand how to reproduce this issue.

sfackler commented 6 years ago

I don't know if there's an easy standalone custom registry implementation.

dwijnand commented 6 years ago

Drats. How about non-standalone? Are there any viable crates.io alternatives that can be used for this?

withoutboats commented 6 years ago

I think these checks should be moved to crates.io entirely :-\

epage commented 11 months ago

Alternatively, with #12235, these warnings will eventually be migrated to being controllable by the user.

See also #4377 for other validation related thoughts.