Crates.io package policies


#21

Are there examples other than the Java ecosystem in which namespaced packages are used? Pub from dartlang does not, I do not think Go does, PyPi does not, do not think Nim does…

All I am saying is that I do not think that the downsides of namespaces, of having packages with the same name which confuses people, is worth the little benefit of having packages with the same name…


#22

I am convinced; flat is the way to go.

But this leaves us with an unfortunate bit of inconsistency. To resolve that, I feel Rust should eliminate namespacing in all its unnecessary forms. After all, if programmers are forced to keep all their code in a single, flat directory and namespace, it will encourage more meaningful and memorable names for items and source files!

Obviously, names would need to be globally unique across all linked crates, including ones you’ve never seen before locked away in private repositories, but again, that just encourages good naming!

And if people really feel compelled to use namespacing, they can always prefix their structs and functions with some unique word. After all, if it was good enough for C, Objective-C, and FORTRAN, I fail to see why it won’t work today!

Remember, those languages were surely designed by experts, and I’m sure they knew what they were doing!


I don’t buy “appeal to tradition” arguments; such are the death of innovation and progress [1]. Nor do I buy the “you can fake them” argument, not when namespaces have become a must-have feature in any language designed in the last twenty odd years. You can fake string literals with arrays of integers, but any language trying that would be laughed out of the room.

Yes, yes, I know the two are not exactly the same thing. Fairly different things, really. But I still feel that the reasons for having namespaces, logical and organisational grouping, are as relevant to a package index as they are to filesystems and source code.

Does it really add that much complexity to (at least for the moment) just require all package names to be of the form “owner/name” with a special exception for “official” packages? Sure, I’d love arbitrary hierarchies (grabbag and grabbag/macros makes the relationship much clearer than grabbag and grabbag_macros), but just namespacing by a completely arbitrary, unchecked prefix would do a world of good.

+1 for namespaces, even if it’s just one layer deep with usernames or some other arbitrary prefix.


[1] Though, obviously, that doesn’t mean history should be ignored; merely that the reasons behind old decisions should be re-evaluated rather than taken at face value. Maybe C lacked namespaces because code bases were smaller, there was less of a “library all the things!” culture, and there were serious technical limitations that forced “simple over elegant” design. Just sayin’ :slight_smile:


#23

Programming languages are much more prone to collisions in namespaces, such as how Rust resolved to have many Error types, such as io::error, and fmt::error.

I am only saying it is not as useful in the context of package management as people think. The Java ecosystem has it, and it is barely, if at all used.

The value of having a unique name > the value of having two packages with the same name


#24

My desire for namespaces stems not so much from naming conflicts as it does from organizational purposes. Being able to group a whole bunch of related crates under a first class namespace is a lot nicer than manually namespacing everything. Especially if we do get rid of hyphens, having foo/bar just looks nicer than foo_bar. Go ahead and let people continue to throw things blindly into the global namespace and have people deal with name collisions. Just give us a way to namespace things when we really want that organizational scheme.


#25

If package names can contain “/”, you could create ad hoc namespaces by making Cargo packages with names like win32/bcrypt-sys that contain Rust crates with names like bcrypt_sys or something. Maybe a community effort to create these conventions is what’s needed to push Crates into supporting proper namespacing.


#26

I think it would be more useful to have each project require a unique name, rather than each crate. The project is where creative names (exciting brands?) make the most sense to me.

Of the approaches I’ve seen, I think the following would be the best:

  • Implement a simple hierarchy: project/crate.
  • Allow users to create and be part of any number of projects (not user namespaced).
  • If a dependency doesn’t specify a project namespace, assume it to be the same as the crate name (e.g., just piston would expand to piston/piston, referring to the game engine, while piston/graphics would refer to the 2D graphics library). This is useful shorthand for the common case where a project only consists of a single crate, or has a flagship crate along with some extras.
  • Make project names first come, first served.

This has several advantages:

  • Projects providing many packages (e.g., wrapping various Windows APIs) could group them together. Packages could be named after their function (e.g., the API being wrapped), while still allowing a unique name for the project. (If I start a project to wrap a bunch of APIs, I don’t want to have to come up with an “exciting brand” for every single API I’m wrapping. Instead, I want to come up with an interesting name for the project, while keeping the crate names clear.)
  • Crates belonging to a project are grouped. This makes it easy, e.g., to see all of the APIs wrappers provided by a give project.
  • Projects can still build unique brands, but now for the project as a whole instead of for each little piece.
  • Existing crates can be renamed from foo to foo/foo without breaking any existing dependencies. (It’d be good to provide a grace period to allow existing projects that decide to group their crates to request their old, redundant versions get removed.)

#27

There’s still a conflict in the policy. From the one side, the packages published are never removed, even though their author wants to. It is good for repository consistency and as a protection from vandalism, but restricts the author.

From the other side, the legal restrictions, such as DMCA, can lead to package removal or even transfer to the trademark owner, what would break the consistency and lead to possible security issues. The package owner also gets fun workaround if they really wants to remove the package: register package name as trademark and request its removal. Stupid, but gives the copyright owners more rights then plain users have.

Anyway, if the package removal is requested, what can be done? The least is automated rename of the package (if the copyrighted property in question is package name, not content) and automated update of all the packages dependent from this one. Probably the measures following the removal should be more thoroughly defined in policy. Not limiting the description to only “we will Mozilla Legal’s decision”.


#28

Perhaps, for trademark issues in particular, crates.io could adopt a policy similar to ICANN’s Uniform Domain-Name Dispute-Resolution Policy


#29

That would definitely conflict with the “A more case-by-case policy would be very hard to get right, and would almost certainly result in bad mistakes and and regular controversies.” rule. And I’m not sure if the decision wouldn’t collide with the US laws, applied by Mozilla. Administrator can decide that there’s no “bad faith” in the package, but the company will file the lawsuit against crates.io then.


#30

Open Source is a lot about giving up the idea of the author in full control. The moment the author decides to distribute to crates.io, the thing is out of their hands.

I have a strong feeling you are confusing copyright and trademark law here.


#31

In fact, not at all. One can possibly publish the crate under any license, not copyleft and not conforming with OSI, but even requiring to delete and forget the code immediately after download. In fact the code author has the right to revoke any such crate, because they doesn’t state in it, that code can be redistributed or any permissions granted, or something like that. This could be prevented through the crates.io User Agreement, but currently I don’t see any.

It’s rather my translation issues :frowning: I was definitely speaking about trademark owners.


#32

What will happen if crates.io start running out of free space (and/or of money to support larger hosting)? Will old version of crates be dropped? Will old projects stop being compilable? Will it be easy to restore content from developers machines (like with Git)?

How much crates.io and its crates depend on Mozilla being alive?


#33

For the sake of a discussion, I would stick to “OSI”-approved for “open source”. Otherwise, no discussion can be had at all, as it can be anything.

Well, how does DMCA come into play then (which only applies to copyright)


#34

Well, my point was that may be we should stick the policy, not only discussion :slight_smile:

Ok, probably I’m not so familiar with US laws, I was sure that DMCA also applies to trademark use. Anyway, as far as I understand, DMCA just simplifies request for removal here, while removal on behalf of trademark usage would be done just by the fair will of crates.io, or by court decision.


#35

Crates are hosted on Amazon S3, so it will never run out of space. The design of cargo in that respect is pretty similar to Rubygems.

You can always download the crates and use them without the cargo web service.


#36

Any update on the “Organizations & related packages” feature? What are the current plans for “grouping crates”?


#37

So I’m also highly disappointed by the fact that namespaced packages has been out of the pictures. Package and source code management is defacto equivalent to file management? Who of you has seen a computer with a flat file system? No hierarchy = no order. Some of the reasons for making “creative names” is pure bollocks to me.

  1. Make creative names - I’m not creative bloody hell, would have study arts if I was, I’m a technical person with OSD and I don’t want to have the burden of figuring out a “good” or “bad” name for my package. This argument is so invalid… it is basically fully estetical and unless you like dictatorship it makes no sense. Also, and VERY importantly, if you have namespace you also have the option to write any creative name you want for your package. Noone will ever stop wycats to naming his package as wycats/piston rather than wycats/game-engine. In other words you the freedom to do what you want, while the previous option you are taking away one of the possible freedoms. Even if you want allow packages to be published on flat namespace, but reserve each username or something for each user. If people want let them publish how they want. Otherwise this is so anti open.

  2. Tags are never going to cut it. Hierarchies make sense, not only for source code, not only for industry, they make sense for life on earth, for artificial intelligence, for organizations, for goverments, for games build on top of APIs build on top of game engines, built on top maths libraries … and on and on. Tags are designed as a commentary addition. Also as mentioned if someone uses the same tag, how is that making any difference than the namespaces?

  3. Squatters - they are here to stay and thrive. Whether it is on flat namespace or not it doesn’t matter. However, if you reserve the username namespace for each user, and you don’t allow multiple users, you have some chance of at least putting under some control. Both choices do not really make any difference for this, so this is 100% invalid argument.

  4. The cost of namespacing - they are bad because… you don’t like them? In this thread we still have not been presented with absolutely any reliable, non subjective, reason why namespaces are bad and what is this “cost” associated with them? Is it someone is lazy to write use ba::ba::ba::html as html? The only cost is the initial transition from flat to namespaced crates that’s it. I challenge anyone else to present me with good examples of significant costs of using namespacing, which would somehow be not present in the flat namespace.

  5. Again, if needed allow people to publish both under their username/organiszation/reserved namespace and on the flat. But please don’t take this liberty for I like it so this is what we do reason.


#38

You are free to use the - character to namespace your crates under your preferred username or organization name.


#39

Freeform namespaces aren’t really the same if you can’t reserve that prefix. I would be free to create withoutboats-foo without any input from you, whereas people can trust that you’re involved in anything under github.com/withoutboats/.


#40

That’s why I think it would be good to reserver the namespaces at least per user case, so that there is something that you can trust. Still, there could be an option and to publish at the same time on the flat namespace