Rename library to "lazy-static"

[Ericson2314]

This would be more idiomatic I believe? Remember extern crate lazy_static; will still work.

[Kimundi]

Hm, it would break cargo dependencies and URL though right? I agree that the naming is maybe not that consistent, but fixing it at this point might be to huge a unneeded breaking change.

[Ericson2314]

Since this is in the nursery isn't it potentially destined to become quite official? So as I see it, its a pain in the ass, but would only become more of pain in the ass in the future.

I've never pushed to crates.io, but if you can add custom deprecation messages, the transition wouldn't be so bad. Also keep in mind that while the ecosystem adjusts there's no problem having a transitive dependency on this under both names.

[lambda-fairy]

You can't upload a crate that differs from an existing one by a hyphen or underscore. See RFC 940.

(As an aside: according to the Ruby convention, hyphens are for extensions to other frameworks, not standalone crates. So taking them as a reference, lazy_static is okay.)

[Ericson2314]

@ifairy conversely that means just like ninja editing crates.io to make it existing packages use the hyphen shouldn't break anything.

Based on the crates.io packages I've seen, I'm don't think that's followed.

[Kimundi]

Hi, I'm sincerely sorry for taking so long to respond.

As far as I know renaming the lib still poses the same issues as before. Changes to how crates.io allows name changes would certainly help, but is out of scope for this lib itself.

However, this crate will probably experience a push sometimes in the next months in an effort to bring it up to a stable 1.0 release, which will also revisit this naming issue.

There is also interest from the libs team in general to just merge this lib into std, in which case a renaming would also be unnecessary churn.

[Ericson2314]

@Kimundi I wouldn't sweat it at all :). People's time availability / life priorities change all the time, and a big point of moving things to the nursery is to distribute the maintenance burden.

There is also interest from the libs team in general to just merge this lib into std, in which case a renaming would also be unnecessary churn.

Well, I don't think spin is ready, yet a big usecase of this library is no_std, so I'd at least want this preserved as a crate behind the facade. That means the naming issue won't go away.

[clarfonthey]

Perhaps there could be a way of integrating spin into libcore?

[Ericson2314]

@clarcharr It's not mature enough (I say as a primary developer of spin). Moreover, we really should think twice about why we want things in std, and what that says about the usability of fine-grained dependency graphs. IMO, nirvana for library code should be ending up in separate repos under the rust-lang organization, not the standard library.

There's probably also too much standard library in the rust repo too. But I digress.

[Kimundi]

@Ericson2314: Good point about spin, hadn't really considered that until now.

And yeah, in either case this crate would remain as a legacy fallback so a decision about the name is still relevant then. :)

[Rufflewind]

Honestly, I much prefer crates to have exact same package name as the crate name. Less confusion overall and one fewer "do I write - or _ in Cargo.toml?" to remember.

[dtolnay]

Closing in favor of rust-lang/cargo#2775. Cargo is going to accept lazy-static = "1.0" as equivalent to lazy_static = "1.0".