[swift-build-dev] Namespacing SPM modules (was Re: [swift-dev] Right list?)

[Max Howell]

So here is an example collision:

— Foo
     |——Bar
               |——Foo

Where both Foo modules are different packages.

I tested this situation with the PM already (each swift-module had its own build directory), and it failed to link, I cannot recall the exact reason. Now perhaps there is a way around that (perhaps dylibs and swiftc -module-link-name), if there is then we can avoid this whole situation provided that no single package wants to use two modules with the same name.

So this is not possible:

— Bar
     |——Foo (github.com/foo/Foo)
     |——Foo (github.com/baz/Foo)

But this is:

— Foo (github.com/bar/Foo)
     |——Bar
	     |——Foo (github.com/baz/Foo)

It would still be nice to use two packages with the same name in the same package, but that is hopefully much less likely to happen. However with large dependency graphs it becomes increasingly likely that the example situation will happen.


> On Feb 29, 2016, at 9:51 AM, Max Howell <max.howell at apple.com> wrote:
> 
>> I'm not sure this completely addresses my point... my argument was that while I understand the potential for collision when the major example is something related to "String", it still isn't clear to me that it is common enough to merit such a major feature. My point with examples like LLVM/libjpeg wasn't related to their style of package, but their uniqueness (which I see as a feature).
> 
> It’s not common, but it must be solved. I’m happy for us not to namespace if there is another solution that is just as good.
> 
>> Is the argument that this problem is more severe because we have no index?
> 
> Indeed, it’s more severe because there is no single index. 
> 
>> I think it would be good to see if we can get more data, too (e.g., more examples of collisions, or more evidence from other language communities).
> 
> We can try to get more data, but I’m not sure it’s necessary since even if the data says it happens only 1% of the time we cannot just leave users out in the cold in such situations.
> 
> There are several solutions, but namespacing seems most in the spirit of a decentralized packaging ecosystem that has emerged due to GitHub’s rise to prominence and its username/repo design.
> 
> However I’d be happy with any solution that works and is easy for the user to get on with things in the event go Module name collision.
> 
> Max