:: in package name produces weird error

[oconnor0]

Including :: in the package name on Windows 10 gives the following error:

The filename, directory name, or volume label syntax is incorrect. (os error 123)

If the first two lines of my Cargo.toml are:

[package]
name = "library::core"

I get the above error. If I replace them with:

[package]
name = "library-core"

The package builds correctly.

[Powersource]

Windows doesn't allow : (and some other characters) in file/folder names so it's probably good that cargo stops you from this. Idk if there could be a way around this. https://support.microsoft.com/en-us/kb/177506

[oconnor0]

I don't think there needs to be a way to work around this if the error message is improved to something like package name "library::core" may not contain ":".

[zachlute]

So, it's easy enough to add a better error message for this by just validating the name when constructing a package id. But uh...are there rules somewhere about what constitutes a valid name? It seems like a package containing ":" can NEVER be a valid name, because package names get turned into directories all over the place and that will always fail on Windows.

But what are the actual rules? Is it just the union of all invalid path characters on all supported platforms are invalid characters in package names?

[ehuss]

But what are the actual rules?

It depends on the scenario.

• For rustc, the only restriction is that it contains alphanumeric or _ characters.
• If publishing on crates.io, then the restrictions are:
  • Must match regex [A-Za-z][A-Za-z0-9_-]*
  • Max 64 chars.
  • Not in the reserved listed (which I think is currently): alloc, arena, ast, builtins, collections, compiler-builtins, compiler-rt, compiletest, core, coretest, debug, driver, flate, fmt_macros, grammar, graphviz, macro, macros, proc_macro, rbml, rust-installer, rustbook, rustc, rustc_back, rustc_borrowck, rustc_driver, rustc_llvm, rustc_resolve, rustc_trans, rustc_typeck, rustdoc, rustllvm, rustuv, serialize, std, syntax, test, unicode, nul, con, prn, aux, com1, com2, com3, com4, com5, com6, com7, com8, com9, lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, lpt9
• For cargo init or cargo new:
  • Is alphanumeric or _ or - (dash is converted to _ when passed to rustc).
  • Must not start with a number.
  • Must not be in the reserved list (which is oddly not the same as crates.io):
    • Rust keywords: abstract, alignof, as, become, box, break, const, continue, crate, do, else, enum, extern, false, final, fn, for, if, impl, in, let, loop, macro, match, mod, move, mut, offsetof, override, priv, proc, pub, pure, ref, return, self, sizeof, static, struct, super, test, trait, true, type, typeof, unsafe, unsized, use, virtual, where, while, yield,
    • If it is a binary, cannot be: deps, examples, build, native, incremental

(I'm not 100% certain on this list, but I believe it is correct from looking at the code.)

[zachlute]

So it seems like the sanest thing to do here is just to restrict the package name at parse time to the same restrictions it would have as a package name for cargo new? That seems like a pretty reasonable restriction, though it could break existing packages somebody has manually created, which would still successfully build with Cargo as long as they didn't contain invalid path characters.

I'll put together a PR for that and it will at least spur discussion, I guess!

[zachlute]

Actually, on further thought, it seems like the most straightforward and least potentially broken thing to do is just restrict it to alphanumeric characters, _, and -. That satisfies the rustc case, adds no additional restriction, and removes the potential for broken paths which was the original point here.