code.dlang.org name collision

[schveiguy]

I'm going to repost what I posted in this forum at the suggestion of Walter. I think we need some kind of solution for this sooner rather than later: https://forum.dlang.org/post/p1h4l1$2uo7$1@digitalmars.com

I think currently on code.dlang.org, if you create a library/program for use, it uses the name you choose as a unique identifier for your project.

However, this seems rather open to abuse, or to unnecessary conflicts.

An example, I plan to have iopipe depend (eventually) on Martin Nowak's new io library listed here:

https://github.com/MartinNowak/io

But, there is already an "io" library in dub:

http://code.dlang.org/packages/io

This links to a stale project, https://github.com/jasonwhite/io, not updated since June 2016.

So what does this mean? Jason White's library gets to own the name "io" forever?

It's not fair to Jason, or anyone who links to his project to take it down or change it, but this also seems unfair to anyone who is willing to publish and maintain an io package of their own.

One of the most annoying things I found is that even if I add-local Martin's io repository to dub, it still wants to compile against the code.dlang.org library (this makes sense as we don't want hijacking, but the solution sucks, I have to use a modified version of Martin's dub.sdl file).

Regardless of this example, I'm sure you can see the dilemma here. Should we have an application/approval process for package names? Should we allow the same named packages on dub, but provide a way to disambiguate when specifying dependencies? Other ideas?

What do you all think?

Please read the above link to see some suggestions from WebFreak.

[schveiguy]

As a suggestion, you could have the first person who registers a package named X allow dependencies via "X" alone, and anyone else who registers a package "X" then can only be depended on via "username/X".

So in my example above, depending on "io" would always reference "jasonwhite/io", but if you depended on "MartinNowak/io", then it would fetch the other one. In other words, the first person to register a project name has the honor of getting the short dependency name. But others can add their own projects with that name, you just have to use a longer dependency path.

This should be backwards compatible with everything currently there.

[WalterBright]

My suggestion from the n.g.: perhaps a reasonable solution is to require new packages added to dub to have at least a 6 character name, and it should not be something generic like "io", "file", "network", "time", etc.

[PetarKirov]

We should take a look at how other package manager solve the problem, especially ones with huge number of registered packages like npm and docker. AFAIK, they solve it in a similar way to @schveiguy's suggestion.

[s-ludwig]

As far as I understand it, "scoped packages" for NPM are actually named like @user/package, so it's not just an alias used for disambiguation. So in effect it is just a more explicit way to write it than simply user-package, like it can be done today. If we want to facilitate such a naming scheme, mentioning this in the introductory documentation could be an alternative.

A problem that I see with forcefully tying the "scope" to the GitHub user name is that repositories get moved rather frequently overall, and any scoped references to a moved package would become invalid unless we do automatic permanent forwarding similar to what GitHub does.

To me the main question is wheter this problem is actually big enough to warrant introducing additional complexity or forcing users to avoid certain names. After all, it will automatically settle itself once all the trivial names are in use. And while it can of course happen that someone just chooses "io2" or "io3" as a name, usually as a package author you'd want to have a name that is more recognizable/memorizable anyway, especially if that project is meant seriously as a long-term project.

Stale projects may be a nuisance at times, but you can never know when something gets revived or how long someone may still depend on it (like Sociomantic still using D1 today), so I don't think we can really do anything about it. Maybe if the last change and last download is older than 6 years, it could be flagged for removal?

[schveiguy]

We should not use the github name, but rather the code.dlang.org name. Then it doesn't matter where you store your project, or if you move it around, or anything else.

The biggest problem I see is publishing stuff on code.dlang.org after one has already created and established a library, and finding they have to rename their library in order to publish.

Stale projects are not really an issue I think as long as there is a way to disambiguate.

To me the main question is whether this problem is actually big enough to warrant introducing additional complexity or forcing users to avoid certain names.

How much additional complexity is it though? I'm not even sure dub needs to be updated, if we use a naming scheme that can be valid for the dub.json/sdl syntax, we may just need to update code.dlang.org to alias the current name to the unambiguous name (user + name).

[SingingBush]

I'm in favour of dub packages using a combination of organisation and project name. This has been dealt with in the Java world. See http://search.maven.org/#search%7Cga%7C1%7CSpring

The combination of groupId (should be a domain in reverse) and artifact make a maven package unique.

[Herringway]

IMO the current set of packages should be frozen entirely - i.e. dub would be frozen at (as of the time of writing) v1.12.0, while dlang/dub (or whatever namespace is chosen) would continue to be updated. That way, old packages relying on the current schema would continue to work while updated packages would be pushed towards the new one.

[whitebyte]

Just another 2 cents: PHP's Packagist uses vendor/package scheme for naming and it looks nice. Rubygems, on the other hand, uses a flat naming scheme, just like DUB now. You can see results: https://rubygems.org/gems?letter=A

[SingingBush]

It's a shame this didn't get any traction. Is there any likelyhood of it being added in the future?

[Herringway]

I'd say yes, it just needs someone to get it the attention and work it needs