Cargo problems - namespacing

It is better to introduce namespace!

I know this is an old issue, but in light of the recent events over at NPM, I decided to look for this to add my thoughts. If you aren't familiar with what's been happening in NodeJS land, here's a quick little summary: How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript • The Register

I'd like to argue that Kik would have been less eager to bring the hammer in the first place if Azer's package was namespaced (I'll bet Kik was hoping to release a node SDK or such).

At the very least we should learn from this and make sure there's a defined takedown/restoration policy for crates.io (there may be one, but I couldn't find it).

It's important to note that kik never brought any hammers https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d

Ya, that's definitely an important clarification – I definitely sympathize with them a bit here (especially given Azer's hostility).

Again, I just wanted to resurrect this topic in the light of current events, as it seemed relevant. I think the idea of vendor name spaces (even if there continue to be root-level aliases to prefixed package) would prevent a whole category of disputes. I quite like the approach that DockerHub took with their registry, where everything is namespaced by the owning organization, but "official" packages for popular images get a root-level name and a badge.

It also addresses the security concerns of what happens when a package is unpublished and then re-published by a different owner.

Might be a strategy to consider further down the road, as all existing packages could retain their root level "alias" for backwards compatibility.

1 Like

our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that

They threatened the package author like that, that's definitely being a dick.

Composer, php's package manager, also uses namespaces.

I think it would be nice to have namespaced creates, but I wouldn't break things for it.

1 Like

To show how [Composer] (http://getcomposer.org) is an example of a namespaced package manager that works really well, take the [Symfony] (http://symfony.com) project. It is both a framework and a collections of libraries. [Searching for it in packagist.org] (Packagist) shows all its packages under the symfony namespace and you can tell very easily which packages are provided by the Symfony project.

If this discussion ever arises again, we should take Composer as a "success story".

I'm willing to, but also would like to point out issues. For example:

console is a library that integrates console into nette. The name gets overloaded very quickly :).

I'm also not sure why symphony-console wouldn't have solved this quite as well?

This looks like a bad name choice. If it were joseki/nette-symphony-console it would be far less ambiguous.

Let's take, for example, the [Django framework] (https://www.djangoproject.com/) in the Python world, there is [a lot of packages] (Search results · PyPI) prefixed with django-, none of them provided by the Django project, with [one exception] (django-localflavor · PyPI).

Another example is Ruby on Rails, there are [several packages] (search | RubyGems.org | your community gem host) prefixed and suffixed with rails and some of them are part of the Rails project.

But despite these cases, I don't see many people complaining about pip or rubygems (I never heard any complaint, actually).

I, for my part think that the namespacing approach is a good idea. There are several projects out there in the wild taking advantage of it.

Just look at GitHub and the repos, which are named in a namespace manner to enable forking, but if you integrate it in software like vim-plug, a pluginmanager for vim, it get's pretty obvious that it is a good idea to e.g. distinct forks or prevent security problems that way.

It is just clean and immediately shows you who is responsible for that package.

Edit: Another important aspect is that people stop reserving package names.

2 Likes

One problem arising would be the official-status which was solved well by docker and could help with the transition.

Imagine how awful it would be if GitHub did not include the username or orgname in a repository's URL path. Imagine that, instead, you had to come up with a world-wide, globally, unique name for your GitHub repo. Imagine you want to create a new GitHub repository for handling base64 encoding. Some people might prepend their username, joe-base64, others might post-pend it base64-sue, others will get creative beast64. Some people will create new repos as soon as they think of an idea and discover the name they want is not taken yet.

What a nightmare.

This is exactly what we have with crates.io (and NPM and Ruby Gems) and it is terrible.

It is most definitely a bug, not a feature.

[Edit]: I'll probably be scolded for adding on to an old thread. Every now and then I search to see what the status of this problem is...

1 Like

This is a five-year-old thread. People interested in the current state of things might want to check out the Packages As Optional Namespaces proposal proposal and prototype developed by members of the crates.io team and others. See the internals thread for more discussion.

2 Likes