Do not rename packages on cargo new.
#5013
Conversation
|
r? @matklad (rust_highfive has picked a reviewer for you, use r? to override) |
Prior to this commit, packages beginning with `rust` or ending with `rs` were renamed automatically when created, unless they were binaries. The ostensible purpose of this code was to avoid people uploading "redundant" names to crates.io, which is a repository of Rust packages. This behavior was overly opinionated. It is not cargo's responsibility to discourage users from naming their packages any particular way. Without a sound technical reasons why packages cannot be named a certain way, cargo should not be intervening in users' package naming decisions. It also did this by automatically renaming the package for the user, as opposed to erroring. Though it printed a message about the behavior, it did not give the user a choice to abort the process; to overrule cargo they had to delete the new project and start again using the `--name` argument. `cargo new` is many users' first entrypoint to the Rust ecosystem. This behavior teaches a user that Rust is opinionated and magical, both of which are divisive attributes for a tool, and attributes which do not generally describe Rust's attitude toward things like names and formatting. If crates.io wishes to enforce that users not upload packages with names like this, it should be enforced by crates.io at publish time.
1bd3f60 to
e101b92
Compare
|
Funny enough, I myself was once frustrated by “you can’t name package lang-x” error, when I was learning some language (Clojure perhaps? I don’t remember). @bors r+ |
|
📌 Commit e101b92 has been approved by |
Do not rename packages on `cargo new`. Prior to this commit, packages beginning with `rust` or ending with `rs` were renamed automatically when created, unless they were binaries. The ostensible purpose of this code was to avoid people uploading "redundant" names to crates.io, which is a repository of Rust packages. This behavior was overly opinionated. It is not cargo's responsibility to discourage users from naming their packages any particular way. Without a sound technical reasons why packages cannot be named a certain way, cargo should not be intervening in users' package naming decisions. It also did this by automatically renaming the package for the user, as opposed to erroring. Though it printed a message about the behavior, it did not give the user a choice to abort the process; to overrule cargo they had to delete the new project and start again using the `--name` argument. `cargo new` is many users' first entrypoint to the Rust ecosystem. This behavior teaches a user that Rust is opinionated and magical, both of which are divisive attributes for a tool, and attributes which do not generally describe Rust's attitude toward things like names and formatting. If crates.io wishes to enforce that users not upload packages with names like this, it should be enforced by crates.io at publish time.
|
Hm, this also reminds me about “cargo new should create a binary by default”. Have we actually decided something about that issue? The discussion seems inconclusive: https://internals.rust-lang.org/t/should-cargo-new-default-to-applications/3772/27. IntelliJ has been defaulting to “—bin” for more than a year now, and it is one of the few places where IntelliJ overrides Cargo defaults. |
|
☀️ Test successful - status-appveyor, status-travis |
|
I liked this feature and I'm kinda surprised this was accepted so fast. The change seems even more opinionated than the behaviour it removed. |
|
@nox could you elaborate why do you think this feature is useful? To me, arguments "Cargo should not scare new users by silently doing something different" and "validation should be strict and belong to crates.io" seem very compelling. cc @rust-lang/cargo EDIT: to make it clear, I don't think we need any validation here, but, if we indeed chose to forbid some names, we need to forbid them for real. |
|
Validation on crates.io only moves the frustration to even later, when the code compiles and runs but suddenly you can't publish because your package is rejected. What is the purpose of having a And more generally, where do we draw the line for breaking changes (this is one) landing without discussion (AFAIK)? |
I think there's a high chance that the very first crate a new Rust programmer creates is And I am certainly sure that not silently renaming the crate in some cases would be a less confusing behavior? Like, this just removes special case, so it must be less confusing?
Why do you think this is a breaking change? Like, it certainly is a slight behavioral change, and, technically, any change can be considered breaking, but I don't think anyone really depends on As I considered it a "minor, non breaking change" and I found the motivation very compelling (I've hit a similar problem in some other language, so I might be biased), I decided that "two people think that this is a good idea" is a strong enough consensus in this particular case. I certainly would want to back out this change if it indeed breaks some code, or if other folks are sure that the current behavior is better :-) |
|
I don’t think *any* breaking change (and it is one to people who would have expected the prefix to be stripped) should be allowed to land just because a couple of people considered it was a good idea. This seems quite at odds with how we do things with RFCs etc elsewhere.
Whether this one should land or not is debatable for sure (I would have preferred an info message saying the prefix was stripped), but that discussion didn’t happen at all.
|
|
Hm, so I looks like I was wrong in my assessment of this change as "minor and non breaking" :-( Let's see what other folks from @rust-lang/cargo think! Thanks for calling this out, @nox! |
|
I am in favor of this change, I see this as a bug that produces unexpected behavior that we are fixing. This is aimed at eliminating frustration for new users; existing users know enough to name their directories rust-foo and their packages foo by hand. I am also against adding validations to crates.io preventing rust-* named crates from being published; I don't think it's a problem. |
|
(This change should at least be listed in the next release's changelog, if it stays.) |
|
@nox, fwiw, this change was discussed with the entire Cargo team, but was not deemed significant enough to merit going through a full RFC process. The teams need the ability to make small decisions without huge process overhead. |
|
I'm in favor of this change. However, I would propose that we announce it in This Week in Rust while it's still in nightly, and give people plenty of time to offer feedback before it becomes stable. Also, we might want to warn about names that crates.io won't accept, as a heads-up. |
|
I also agree with Carol that crates.io should not reject these names either. My comment about crates.io was that that on upload is the correct place to put this validation if we actually wanted to have it. |
I think this is also a good idea, for the same reason I laid out in 2016 - new users are much more likely want bin, and users who are not new know how to solve the problem. If we want to make that change, it would be best to bundle these changes in the same release. |
|
If we change the default to creating a binary, could we add this back in as a warning when making a library crate? I don't think this matters at all when making a binary, but it seems useful to remind that 'rust-' is redundant when someone starts a new library. |
|
If we do add a warning, it could remind that the package name for crates.io doesn’t have to be the same as the repository name. For example, https://crates.io/crates/url is not prefixed but https://github.com/servo/rust-url is. |
|
I don't see how it is useful to anyone if the crate names have Using those prefixes/suffixes in repository/folder names on the other hand is clearly useful. (I'd also prefer if crates.io would enforce package name == crate name. Hi there, xml-rs!) |
|
I would probably feel OK either way if this starts as the default. This change though creates confusion for existing users by asking user to notice and relearn the default after several years without significant benefit. I feel that there are increasingly more changes that do not take into account the cost of changing widely accepted behavior. This will frustrate users that want a "boring" and predictable language since they will constantly see surprises in the new compiler version, which requires them to follow closely to what the community does or read every release notes, and adapt existing tool and documentation constantly. |
Prior to this commit, packages beginning with
rustor ending withrswere renamed automatically when created, unless they werebinaries. The ostensible purpose of this code was to avoid people
uploading "redundant" names to crates.io, which is a repository of
Rust packages.
This behavior was overly opinionated. It is not cargo's
responsibility to discourage users from naming their packages any
particular way. Without a sound technical reasons why packages
cannot be named a certain way, cargo should not be intervening in
users' package naming decisions.
It also did this by automatically renaming the package for the
user, as opposed to erroring. Though it printed a message about
the behavior, it did not give the user a choice to abort the
process; to overrule cargo they had to delete the new project
and start again using the
--nameargument.cargo newis many users' first entrypoint to the Rust ecosystem.This behavior teaches a user that Rust is opinionated and magical,
both of which are divisive attributes for a tool, and attributes
which do not generally describe Rust's attitude toward things like
names and formatting.
If crates.io wishes to enforce that users not upload packages with
names like this, it should be enforced by crates.io at publish
time.