Why is Cargo organised as if all contributors belong to a single organization? Other languages have namespaced packaging, but not Rust? Why? It leads to name clashes. Let's say "Some Joe" creates some mediocre implementation of Base64 and creates the base64 crate. Let's say I want to contribute a better implementation. So what do I name my crate? I am forced to do some name mangling or to name it something completely unrelated like avocado. Of course then base64 crate gets 15k downloads and avocado gets close to 0 and I'm left wondering why do I even bother contributing. As number of crates reaches 100 or 1000 times as many, what's the endgame? The namespace saturation will be just immense.

[image] carols10cents: Exactly, that's my point. Namespacing doesn't help with this problem. ...but that isn't the problem described in the original post. The point is that the first crate to get named something like base64 gets a significant "mindshare" advantage over every other competitor based on the name alone. If you have somejoe/base64 and you/base64, there's no immediate reason to prefer one over the other. One doesn't look "more official" than the other. You have to actually look at the release history, documentation, usage numbers, etc. to get a sense for which might be the better option as opposed to "I think I'll take the one with a sensible name over the one named after some weird asian foodstuff or a street in Novgorod." As another point, unrelated to the above, the current system also leads to speculative name reservation. Look at retep998: he's reserved something like four hundred and twenty crate names just so his Win32 bindings don't end up fragmented. And that's not even a complete list of all possible Windows system libraries! Finally, as an aside, I thoroughly reject "they work out fine" as a justification. That something functions does not mean it is perfect and cannot be improved. That is the sort of reasoning that would leave us stuck with C forever: it works out fine, we don't need a better language, we just need to hire more careful programmers!

[image] DanielKeep: The point is that the first crate to get named something like base64 gets a significant "mindshare" advantage over every other competitor based on the name alone. I don't use libraries because of mindshare; I use libraries because they meet my needs. [image] DanielKeep: One doesn't look "more official" than the other. Aside from libraries that are in the rust-lang organization on github, there is no "official". [image] DanielKeep: Finally, as an aside, I thoroughly reject "they work out fine" as a justification. That something functions does not mean it is perfect and cannot be improved. The OP used prior art as justification: [image] RokLenarcic: Other languages have namespaced packaging, but not Rust? I was pointing out that there is significant prior art that made the other choice as well.

[image] DanielKeep: The point is that the first crate to get named something like base64 gets a significant "mindshare" advantage over every other competitor based on the name alone. If you have somejoe/base64 and you/base64, there's no immediate reason to prefer one over the other. One doesn't look "more official" than the other. You have to actually look at the release history, documentation, usage numbers, etc. to get a sense for which might be the better option as opposed to "I think I'll take the one with a sensible name over the one named after some weird asian foodstuff or a street in Novgorod." This isn't a particularly constructive reply and I daresay is somewhat obtuse. The impression I received from reading @carols10cents is that, implied from history of other package managers, is that users will pick the one with most relevant name 9 times out of 10 before moving on their next task. Finding a dependent package to solve a problem when you don't know what package that'll be is a chore. Your counter-argument implies, to me, that you value users doing the investigation and picking "the best one" based on an informed decision. This is admirable, but bear in mind that you're bringing different values and axiomatic assumptions into this discussion. Nevermind whether this is realistic or achievable or just an idea you have about how things should be. Don't assume everything agrees with you or shares the same basic values. And for the record: My opinion on this whole thing (namespacing) is hey! would be nice to have, but really what's proposed here is bikeshedding. If anything, we could be looking at much more sophisticated things like what Joe Armstrong proposed in the past (http://erlang.org/pipermail/erlang-questions/2011-May/058768.html). But that ship has sailed (or, at least, would require an enormous effort that would be fall into "breaking changes" land). EDIT: taking my own advice and toning down my rhetoric.

[image] olsonjeffery: The impression I received from reading @carols10cents is that, implied from history of other package managers, is that users will pick the one with most relevant name 9 times out of 10 before moving on their next task. I did not intend to imply that, actually-- I encourage all users to do due diligence on all their dependencies regardless of what they're named. My point was that whether we have namespacing or not, users will need to do research, so trying to justify namespaces by saying we shouldn't have crates named 'base64' that aren't the best base64 crate isn't convincing to me.

@carols10cents okay, so then would allowing slashes or some other form of nominal namespacing plus metadata serve that goal of finding the best solution to a greater extent? Is this a ux problem on crates.io?

[image] olsonjeffery: Okay, so then would allowing slashes or some crude, nominal namespacing plus metadata surface that to a greater extent? I think projects like Awesome Rust that curate crates and aggregate quality crates for different purposes are the best solution rather than namespacing.

RRQLDR: Names matter, namespacing gives us more, better names, which means better discoverability, and minimises a source for potential non-technical bias in choosing a crate. [image] carols10cents: I don't use libraries because of mindshare; I use libraries because they meet my needs. [...] Aside from libraries that are in the rust-lang organization on github, there is no "official". So you are always perfectly logical and never make a judgement based on anything other than pure, cold logic? If so, you are a better person than I and, I suspect, the overwhelming majority of humans. I know for a fact I'm influenced by names and branding, even when I'm aware of it and trying not to be influenced. The human mind is a trecherous thing, but I suppose a robot wouldn't understand that. (Pre-emptive note: on the off chance calling carols10cents a robot doesn't make it clear, I'm being facetious. And anyway, some of my favourite people are robots; like CGP Grey.) I've seen people use rustc_serialize over serde purely based on the name: either because the former looks more official (it's even got "serialize" in the name!) or because the latter doesn't say what it does and doesn't even look relevant. Denying that names have power is silly, no matter how inconvenient it may be. As another aside (why, oh why, can't text be a directed graph?): the reason I said "a street in Novgorod" was that I was going to use an example of a new XML parser library I saw recently... except it's name was so completely arbitrary, I honestly can't remember what it was called. It might as well have been named with random syllables, or a 16-digit hexadecimal number. This is the sort of thing I seriously worry about for crates.io: a future of arbitrarily-named and impossible to remember crates. Perhaps it would be best to explicitly say that I (and I think it's not unreasonable to say there are others who agree with me) view the "creative package naming" that seems to frequently happen with non-namespaced package indexes as a bug, not a feature. A name should, as much as possible, say what something is and/or does. Not having namespaces appears to create (or at least contribute) to this problem, having namespaces appears to ameliorate it; thus, namespaces have merit over no-namespaces. [image] carols10cents: The OP used prior art as justification: [...] I interpreted that as justification for asking the question in the first place (the very next word after your quote was "Why?"), not as justification for the proposal. What's more, the OP went on to provide an actual justifying concern: name collisions. That said, having pointed it out, I can see how it could be read in an accusatory tone, so fair enough: @RokLenarcic: carol10cents is right: just because other languages have namespaced packaging is not, itself, a reason for Rust to have it. [image] olsonjeffery: [...] users will pick the one with most relevant name 9 times out of 10 before moving on their next task. And that is something I believe to be a problem. [image] olsonjeffery: Finding a dependent package to solve a problem when you don't know what package that'll be is a chore. Your counter-argument implies, to me, that you value users doing the investigation and picking "the best one" based on an informed decision. My position is that the name should not add to the user's problems. If they see base64 and denniston, which are they more likely to pick? Ideally, they'd consider both equally, but people are lazy (conservation of effort is a perfectly reasonable thing!), and if someone's in a hurry, are they even going to realise that denniston is an option? If they don't check, how will they know that base64 is largely functional but minimal, whilst denniston is newer and more performant? If they're both called */base64, then at least it's clear that a reasonable choice exists. They might pick one arbitrarily over the other, but at least they can't claim "oh, I didn't even know there was another one!" As I've mentioned above, I've seen people react with surprise to the existence of serde. If you're looking for a serialisation library, why on earth would you even look at something called "serde"? (That's actually a bit unfair on "serde"; as far as I know, the name is a contraction of "serialisation, deserialisation"; kinda like "codec". But again, cute names are dangerous. :slight_smile: ) [image] olsonjeffery: Don't assume everything agrees with you or shares the same basic values. If I assumed that, why on earth would I be here trying to convince people that my perspective has more merit than the alternative? I'd just sit back, safe in the knowledge that all discussions that don't agree with my views are just sarcastic joking about how silly anyone who theoretically disagrees is (not that anyone would). [image] olsonjeffery: what's proposed here is bikeshedding No one's going to die if namespacing isn't introduced, true enough. It's not quite on the level of "what colour should the background of crates.io be?", though. I mean, it looks like a pool table. It's not unpleasant, but why? I thought Rust was going for flat and sanitised, not "classy English pub". Shouldn't it conjure imagines of a warehouse, or even a dock? [image] olsonjeffery: If anything, we could be looking at much more sophisticated things like what Joe Armstrong proposed in the past (...). As someone who likes organising things into neat collections, that post is horrifying. [image] carols10cents: I think projects like Awesome Rust that curate crates and aggregate quality crates for different purposes are the best solution rather than namespacing. I think they're certainly good to have, but not a solution in and of themselves. The "Data Structures" section doesn't list the various alternative data structures that were spun out of collect-rs. I forget all the names at the moment; they might be in another section, but that's the one I'd expect them in. (Also, why is "serde" in "Data Structures"? I expected to find it under "Encoding". Why isn't the maintainer's brain arranged the same way mine is? 'Tis a shocking oversight, I tell you, shocking!) Namespacing means better names, which means there's an additional mechanism for users to find relevant crates. More discovery is a good thing (or at least, I'd hope so). Actually, given the recent creation of stdx, it might be nice to have some sort of more formal aggregation mechanism built into crates.io. But that's starting to sound like Steam Curators, and I'm not sure we want to go down that particular garden path... (It stands for "Really Rather Quite Long, Didn't Read".)

I totally agree, take for example the Iron repo has crates called session, persistent, cookie, and router etc. The names are so vague that you can't tell they have anything to do with Iron's middleware layer. This also means that all the other web frameworks can't use those names. At least with conduit they are all prefixed like conduit-router, conduit-router, conduit-static. If they were namespaced as iron-persistent and iron-router it would add so much context. I feel like it's a hipster thing to give your libraries cool names, but that doesn't help someone who's reading a code base for the first time as they will need to lookup everything in github just to see what it does.

[image] DanielKeep: The human mind is a trecherous thing, but I suppose a robot wouldn't understand that. (Pre-emptive note: on the off chance calling carols10cents a robot doesn't make it clear, I'm being facetious. And anyway, some of my favourite people are robots; like CGP Grey.) gasp YOU'VE DISCOVERED MY SECRET BEEP BOOP

[image] DanielKeep: Names matter, namespacing gives us more, better names If we put your other arguments aside for a second, and really do consider that names matter, aesthetically "base64" is a lot more pleasing than "somejoe/base64" You seem to want to foist less aesthetically pleasing, harder to remember names on everyone, lest someone who claims a good name get an unfair advantage. While that may be a valid point in and of itself, from a purely qualitative perspective, I think you're arguing for aesthetically uglier, harder to remember names, by removing the ability to have shorter, more aesthetically pleasing ones. Really I think what you're after is a sort of "fairness" to the naming scheme, not high-quality names. If the latter is what you're actually after, I think mandatory namespaces are detremental.

Cargo problems - namespacing

carols10cents July 14, 2015, 3:12pm 11

I think projects like Awesome Rust that curate crates and aggregate quality crates for different purposes are the best solution rather than namespacing.

Topic		Replies	Views
Pre RFC: We need a process for giving crates to new maintainers	32	4147	November 25, 2016
Dude has ~100 empty crates with the most common names. Is that ok? community	29	5151	June 28, 2019
Should people be allowed to "reserve" crate names?	39	8565	August 25, 2018
How to guarantee the sustainability of Rust crates ?! community	29	2236	May 22, 2024
Package and crate naming convention help	22	8145	November 14, 2021

Cargo problems - namespacing

Related topics