+1 to treat crate names as identifiers and forbid hyphens. Lets take the pain now rather than live in pain forever.
2 Likes
Iād also advocate just removing hyphens and requiring underscores, at least for 1.0. Post-1.0, new facilities (like namespaces) could be added, and restrictions on names can be loosened if itās determined that they are too tight, but itād be impossible to tighten the symbol-naming restrictions post-1.0 in a backwards-compatible way. So the safe path forward seems (to me) to be using the more-restrictive option until the less-restrictive option gets more fully fleshed out.
For whatever itās worth, I also prefer hyphens to underscores aesthetically, and I also like the ability to rename crates on import, so the status-quo isnāt that bad, for me. BUT I also feel like the current design is not that future-proof (if something like namespaces get folded in, in particular), so rather than have 1.0 block on getting the right design right now, Iād like to see the current behavior stripped to its future-proof essence, so that a better facility could be added even after 1.0 (if thatās how long it takes to design).
2 Likes
For esthetic reasons I prefer dashes in file names, however I agree that having crate names as valid Rust identifiers is a strong reason to disallow them. For Rust adoption in the enterprise we should add namespaces at some point and it will remove namespace as an use case for dashes.
Should I start a separate RFC for namespaces or has this already been discussed and decided upon?
+1 for forbidding dashes to stay consistent with identifiers. When I was learning Cargo I got the false impression that hyphens were a de-facto standard, and then got totally tripped up on where to use a dash vs. an underscore in the repo name, the .toml name, the name in the import statement, etcā¦ This is part of the reason I have referred to the module system as non-obvious in some other threads. New users should not have to think about this; they should just see that everyone is using underscores everywhere, follow that, and have things ājust workā.
Keep in mind that the vast majority of Rust code has never been written, most Rust users have not even tried Rust yet, and most of the code out there now will be broken before 1.0 anyway.
@retep998, thanks for being so gracious about this proposal; I hope it is both fixed AND you get a convient migration path!
1 Like
What about repurposing using the #[link] attribute (or creating a new one, if thatās confusing) to set the crate name (and presumably allowing dots too), instead of having special syntax for this?
#[link(name = "windows.data.pdf.lib")]
extern crate windows_pdf;
1 Like
@DanielKeep are you still working on this?
I very much support this proposal, and would be happy to pick up where you left off.
Iām partway through writing up the revised version, taking the comments into account.
The hard part isā¦ looks around I really want hyphens to stay on in some form, but I canāt reconcile that with the overwhelming āonly idents everywhereā position that is, logically, the most reasonable: no rule to have it explain is better than any rule that has to be explained.
At this point, Iām just going to have to just lie in the bed I made and work out how in the hell to transition retepās twenty zillionty hyphenated packages.
I might leave the door open by writing it up as āno hyphens anywhere at allā¦ at least until after 1.0ā.
1 Like
I would favor using hyphens in package names but simply having a convention, perhaps enforced by Cargo by default, that hyphenated package names produce underscored crate names.
You can already name the ālibā crate name for a package to whatever you want, I believe.
2 Likes
I think we can implement that as a lint in rustc, actually.
Something like this:
warning: crate names with hyphens ("foo-bar") are awkward to use, #[warn(hyphenated_names)] on by default
help: consider renaming the crate with #![crate_name="foo_bar"]
Thatās one idea! The help might be better if it were more Cargo-oriented, since the preferred way to specify a Cargo crate (not package name) is to use [lib] name = "whatever".
Like this:
[package]
name = "iron-fizzbuzz-middleware"
version = "0.0.1"
authors = ["Tom Jakubowski <tom@crystae.net>"]
[lib]
name = "iron_fizzbuzz_middleware" # or even "fizzbuzz_middleware", to use pseudo package namespacing
EDIT: See better proposal below
Of course! Would something like this:
warning: crate names with hyphens ("foo-bar") are awkward to use, #[warn(hyphenated_names)] on by default
help: consider renaming the crate in your Cargo.toml:
[lib]
name = "foo_bar"
help: alternatively, add #![crate_name="foo_bar"] to the crate root
work for you? Itās hard to explain the whole fix without bloating the message too much; I think it can be tweaked more.
I want to keep it as a rustc lint, because:
-
Hyphenated names are awkward in general, not just with Cargo-ified libraries;
-
If the user really wants a hyphenated crate name, they can silence the warning using the existing infrastructure (
#[allow]or-A). I donāt think thereās a good way to silence Cargo warnings (feel free to correct me on this).
Actually it would be nice if rustc detected if it was being called by Cargo or not, and gave an appropriate suggestion based on that. Maybe an environment variable or something. But Iām not sure whether thatās worth the extra complexity in the compiler.
The more I think about it, the more Iām convinced that we should just have Cargo warn unconditionally on hyphenated crate (not package) names. Someone along the line will need to rename the crate anyway; better it be the maintainer, not the user.
People who donāt use Cargo will miss out on the warning, but I think we can live with that.
EDIT: Okay, I think Iāve got it down to a concrete proposal:
-
If a user invokes
cargo newwith a hyphenated name, and the--binoption is not present, automatically apply the Jakubowski renaming trick on the crate name (not the package name).- Rationale: Hyphenated names are bad for library crates, but for executables it doesnāt matter.
-
If an existing (library) package has a hyphenated crate name (not the package name), Cargo should warn every time the package is built. The warning should include a short explanation of the problem, plus a snippet that the user can paste right into their Cargo.toml.
-
On crates.io, reject any new uploads which would warn under part 2. This change can come after a grace period, so that everyone has a chance to be warned in Cargo first.
@alexcrichton @DanielKeep @retep998 @tomjakubowski @everyone-else Does this sound reasonable to you all?
I came into this thread expecting to be completely against it (Iām a big believer in aesthetics) but these proposals sound eminently reasonable to me. Iād prefer if we could use hyphenated identifiers of course, but thatās a much bigger change :āD
Iāve had to step away from Rust things (actually almost all things) lately, and I canāt finish up the RFC. @lfairy, as you already asked about this, I would appreciate it if youād see it to the end.
My advice, given the rapidly approaching beta release is to go with this:
-
Immediately deprecate hyphens if feasible, given where the check is in the compiler. If not, forbid. This should preferably only apply to extern crates, but this can be changed backward-compatibly later for binaries.
-
Add renaming support to Cargo. Full dependencies can use a
link-assetting. Short dependencies could be extended to use something like:rustc_serialize = "rustc-serialize @ ^0.1"; a word followed by@is the renaming part. -
Adjust crates.io to show this pre-renamed syntax for existing crates with hyphens.
The above should be done preferably before beta, definitely before 1.0. Other issues, like whether or not to block new hyphenated crates, etc. can be dealt with later in a backward-compatible fashion.
This also will hopefully cause a minimum of disruption: it requires only a minor front-end change to crates.io and no changes to the backend (hopefully).
Again, apologies for dropping the ball on this.
Sure thing. Iām working on it on-and-off between classes; itās slow going but Iāve got a clear idea of what to do now.
Note that as @tomjakubowski said above, the Cargo package name and the rustc crate name are orthogonal and can be defined separately. Hyphens only present a problem in the latter. With that in mind, points 2 and 3 are unnecessary. My draft so far is actually quite short, as it only has to deal with your point 1.
As an aside, a few days ago I side-tracked into repurposing hyphens as namespace separators. But that wound up too complicated so I dropped it. Iām back to banning the things now.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.