Organizations in crates.io

tools and infrastructure cargo
1

I've been wondering if it's worthy qualifying project packages at crates.io by organization.

One reason I see is that it allows versioning projects that have the same name by author. For example, consider the readability comparison from:

use hydroper_air::display as d1;
use harman_air::display as d2;

to:

use hydroper::air::display as d1;
use harman::air::display as d2;

or:

use com::hydroper::air::display as d1;
use com::harman::air::display as d2;

I think this would matter since "air" is a very common name, and different companies like to own products with such name.

2

RFC: Packages as (optional) namespaces by Manishearth · Pull Request #3243 · rust-lang/rfcs · GitHub has some discussion of why it goes for project namespace ownership rather than organization namespace ownership.

4 Likes
3

I was betting that the feature being added to Cargo is focusing on solving only the needs of logical organization of projects, typically containing procedural macro crates.

4

That RFC is focused on providing more options for designing APIs and doesn't as much touch on namespacing by owner. Namespacing by owner is a topic that comes up fairly regularly here with a bunch of trade offs. Most recently, Adam Harvey presented on it at PackagingCon, see https://www.youtube.com/watch?v=1IINSW7IG-k&list=PLl386dCR5QGTElF3MbltCJupNG1lHK4Nr&index=11

I wish at this point we had a document summarizing all of the namespacing-by-organization discussions to make it easier to tread new ground rather than re-hashing the same topics.

4 Likes
5

In my opinion, there is no readability improvement here, and certainly not one that would justify the operational and usability complexity added to crates.io that would be needed to support this.

3 Likes