www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - code.dlang.org name collision

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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?

-Steve

P.S. maybe there is already a solution in place for this, but I'm not 
seeing it.
Dec 21 2017
next sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 21 December 2017 at 20:13:21 UTC, Steven 
Schveighoffer wrote:

 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?

 -Steve

 P.S. maybe there is already a solution in place for this, but 
 I'm not seeing it.


I don't think it should be removed, semver states versions must 
be immutable and never changed. Also there are guaranteed 
packages or programs depending on this which need it and future 
people wouldn't be able to build them if it was removed. Once 
registered they should stay registered forever imo, should just 
take a different name then
Dec 21 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/21/17 3:42 PM, WebFreak001 wrote:


 I don't think it should be removed, semver states versions must be 
 immutable and never changed. Also there are guaranteed packages or 
 programs depending on this which need it and future people wouldn't be 
 able to build them if it was removed. Once registered they should stay 
 registered forever imo, should just take a different name then


Obviously we can't remove or change the names of currently registered 
projects. That isn't an option.

But the result is that code.dlang.org will be full of projects like 
"betterxml" or "xml2" or "xml2018", because each developer abandons some 
work, and now it looks like a complete mess.

Imagine if github was this way, you couldn't name your project after any 
other persons project name! I don't see why we shouldn't be able to 
disambiguate between people's projects somehow, even specifying a 
dependency.

-Steve
Dec 21 2017
parent WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 21 December 2017 at 20:55:40 UTC, Steven 
Schveighoffer wrote:

 On 12/21/17 3:42 PM, WebFreak001 wrote:


 I don't think it should be removed, semver states versions 
 must be immutable and never changed. Also there are guaranteed 
 packages or programs depending on this which need it and 
 future people wouldn't be able to build them if it was 
 removed. Once registered they should stay registered forever 
 imo, should just take a different name then


 Obviously we can't remove or change the names of currently 
 registered projects. That isn't an option.

 But the result is that code.dlang.org will be full of projects 
 like "betterxml" or "xml2" or "xml2018", because each developer 
 abandons some work, and now it looks like a complete mess.

 Imagine if github was this way, you couldn't name your project 
 after any other persons project name! I don't see why we 
 shouldn't be able to disambiguate between people's projects 
 somehow, even specifying a dependency.

 -Steve


well we have colons for subpackages, so we couldn't use those but 
maybe add / which adds an extra level of complexity and would 
require at least a dmd + ldc release including that dub version 
before pushing it to the website. Other than that I actually like 
that idea:

dependency "webfreak/fswatch" version="*"
dependency "webfreak/d2dgame" version="*"
dependency "webfreak/eventsystem" version="*"
Dec 21 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I don't think existing names can be changed - too disruptive.

But moving forward, 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.

Please bring this up with the dub maintainers.
Dec 21 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/21/17 4:55 PM, Walter Bright wrote:

 I don't think existing names can be changed - too disruptive.
 
 But moving forward, 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.
 
 Please bring this up with the dub maintainers.


https://github.com/dlang/dub/issues/1315

I had an idea based on WebFreak's suggestion:

If more than one person registers project "X", then you can depend on 
the earliest project via "X", but must use "username/X" to depend on 
other projects with the same name.

This would be backwards compatible. I'm assuming that you can't actually 
name a project "username/X" now, right?

-Steve
Dec 21 2017
parent reply drug <drug2004 bk.ru> writes:
22.12.2017 01:11, Steven Schveighoffer пишет:

 On 12/21/17 4:55 PM, Walter Bright wrote:

 I don't think existing names can be changed - too disruptive.

 But moving forward, 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.

 Please bring this up with the dub maintainers.


 
 https://github.com/dlang/dub/issues/1315
 
 I had an idea based on WebFreak's suggestion:
 
 If more than one person registers project "X", then you can depend on 
 the earliest project via "X", but must use "username/X" to depend on 
 other projects with the same name.
 
 This would be backwards compatible. I'm assuming that you can't actually 
 name a project "username/X" now, right?
 
 -Steve


We should also consider provider's name - github, bitbucket, gitlab etc. 
Because there can be different (real) users with identical names.
Dec 21 2017
parent reply user1234 <user1234 12.nl> writes:
On Friday, 22 December 2017 at 05:50:15 UTC, drug wrote:

 22.12.2017 01:11, Steven Schveighoffer пишет:

 On 12/21/17 4:55 PM, Walter Bright wrote:
 [...]


 We should also consider provider's name - github, bitbucket, 
 gitlab etc. Because there can be different (real) users with 
 identical names.


So true, it could even open the door to harmful cases of 
hijacking.
Such an extension (same name) needs to be well thought.
Dec 22 2017
parent rjframe <dlang ryanjframe.com> writes:
On Fri, 22 Dec 2017 11:34:21 +0000, user1234 wrote:


 On Friday, 22 December 2017 at 05:50:15 UTC, drug wrote:

 22.12.2017 01:11, Steven Schveighoffer пишет:

 On 12/21/17 4:55 PM, Walter Bright wrote:
 [...]


 We should also consider provider's name - github, bitbucket,
 gitlab etc. Because there can be different (real) users with identical
 names.


 
 So true, it could even open the door to harmful cases of hijacking.
 Such an extension (same name) needs to be well thought.


Using the dub-registered name rather than the provider username wouldn't 
have this problem; and if a person uses multiple providers with different 
usernames, we would have consistency on the registry using a single name.
Dec 22 2017
prev sibling next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 21 December 2017 at 20:13:21 UTC, Steven 
Schveighoffer wrote:

 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?

 -Steve

 P.S. maybe there is already a solution in place for this, but 
 I'm not seeing it.


Great you brought this to attention. During a technical code 
review for a XMake build plugin for D I was asked how a company 
can set the organization name in dub.json to avoid name clashes 
with Dub package names. Maybe we could also have a look how this 
is done in other languages npm/python,...

Kind regards
Andre
Dec 21 2017
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-12-21 21:13, Steven Schveighoffer wrote:


 What do you all think?


What Docker is doing on the public Docker registry [1] is that all 
images are namespaced based on the account name. Instead of just "dwt" 
it would be "jacob-carlborg/dwt". In addition to that they have what 
they call "official images" [2]. These are images residing in the top 
level name space, for example: "ubuntu".

On the other hand, RubyGems has over 133,000+ packages without any form 
of namespacing.

[1] https://hub.docker.com/
[2] https://docs.docker.com/docker-hub/official_repos/

-- 
/Jacob Carlborg
Dec 22 2017