[swift-build-dev] [swift-dev] Right list?

[Daniel Dunbar]

Can you explain a little more about your motivation for this?

I understand that "SwiftString", as a package, may be something which is likely to conflict. It isn't however clear to me that most packages fall into that category, or that it is even desirable to support features that encourage it.

For packages like "libjpeg", "LLVM", "OpenGL", "ncurses", "zlib", it seems like having one global namespace is OK, and even useful. As a Python user, for example, I have never been bother that the Python package index is a global namespace.

Is part of your motivation that you expect a different usage of Packages in the Swift ecosystem? I can see how if the expectation is that there are a lot of micro-framework style packages for basic functionality (i.e., "CountedCollections" or "GraphAlgorithms") that maybe the usage patterns would lend themselves to more conflicts.

 - Daniel

> On Feb 26, 2016, at 9:30 AM, Erica Sadun via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
>> 
>> On Feb 19, 2016, at 5:50 PM, Max Howell <max.howell at apple.com <mailto:max.howell at apple.com>> wrote:
>> 
>> Yes, we should probably take this to swift-build-dev.
>> 
>>> I'd like to add a Package property to namespace packages by origin,
>> 
>> Some namespacing will certainly be required, the sooner the better.
>> I was hoping to namespace with github username where possible, it’s mxcl’s PromiseKit after all.
>> 
>>> and to add aliases in Swift for renaming imports.
>> 
>> With namespacing we probably wouldn’t need this solution, which would be more ideal, eg:
>> 
>>    import Foo
>> 
>> Now you have two Foo, so any package that uses both must be specific:
>> 
>>    import mxcl.Foo
>>    import erica.Foo
>> 
>> Provided they are compiled such that the build system knows the namespaces at all times, we should be good. It’s only the user who doesn’t need to know at all times.
> 
> Following up on this.
> 
> I first brought this topic up on swift-dev, and was pointed to swift-build-dev.
> 
> Having spent considerable time messing up my Swift packages by giving them ridiculously obvious names like SwiftString and SwiftCollections, I realized that namespacing would be a solution for disambiguating conflicts. import SwiftString is insufficient when several packages are named SwiftString. 
> 
> When you have two identically named packages, the module imports need to distinguish both the sources as well as references defined per package. Although SwiftPM finds packages using git URLs and module names, I do not believe that origin is addressable or usable. Plus, throughout the lifetime of a package, that origin could potentially move from, for example, GitHub to Bitbucket. 
> 
> I suggest using some kind of origin key for differentiation. The simplest solutions for these include reverse domain names (basically a company/source identifier), git URLs (the current location of the repo), Github/Bitbucket user names (which are similar to a company/source identifier but more subject to updates over time). 
> 
> Of these, I’d recommend reverse domain for the following reasons: 
> 
> They are relatively short
> They are already well established for Apple app distribution
> They do not rely on a web address that may change should the repo move
> They are less likely to conflict with user names across repo hosts
> I’d imagine a package declaration that looks something like this:
> 
> import PackageDescription
> 
> let package = Package(
>     name:   "SwiftString"
>     origin: "org.sadun"
> )
> In the case of name conflicts instead of importing SwiftString, you’d prefix an origin:
> 
> import org.sadun.SwiftString
> import com.foobar.SwiftString
> Ideally, you could further alias these to shorten symbol disambiguation:
> 
> import org.sadun.SwiftString as SadunStrings
> import com.foobar.SwiftString as FoobarStrings
> 
> // Unique to only one package, no name conflict
> uniqueMethod("Hello World")
> 
> // name collision disambiguation
> SadunStrings.sharedMethod("Hello World")
> I'm interested in hearing any feedback and thoughts about whether this is possible and what I could do to help further this idea.
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160226/fad7f379/attachment.html>