Package module name collisions

Jason_Lee · February 2, 2016, 1:41am

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

···

Sent from my iPhone

Erica_Sadun · February 2, 2016, 1:53am

This is a good reason why package names should be clear and specific, avoiding common phrases and terms that will overlap.
A proven way to avoid such issues is to namespace your packages in some way, e.g. prefer SadunStringUtilities vs SwiftString.

At this time there is no built-in way that I know of how to deal with module name collisions. So let me speculate about what
a solution might look like. (Skip to the next message if this doesn't interest.) Having a reverse domain name as
part of the Package declaration syntax maybe could address part of the issue, for example:

import PackageDescription

let package = Package(
name: "SwiftString"
origin: "com.sadun"
)

and in the case of name conflicts use:

import com.sadun.SwiftString
import com.LeeJason.SwiftString

with all the annoying resolution that might involve in disambiguating symbols. I could also
see some kind of package alias being needed if this problem got too bad, e.g.

packagealias Sadun = com.sadun.SwiftString
packagealias LeeJ = com.lLeeJason.SwiftString

let x = LeeJ.countStringItems(someString)

but I don't know how Swift would disambiguate, for example, two packages that both created
public extensions on String both being imported into the same file, and both offering conflicting, say, properties.

-- Erica

···

On Feb 1, 2016, at 6:41 PM, Jason Lee via swift-users <swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Zhao_Xin · February 2, 2016, 1:54am

Have you tried typealias? typealias NewTypeName =
Module.TypeInsideModuleName

zhaoxin

···

On Tue, Feb 2, 2016 at 9:41 AM, Jason Lee via swift-users < swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought
over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package
and everything is working well for me. However, when I got this conflict
today, I was thinking this will be a problem going forward. I'm sure it's
been solved already by the package manager team, but I haven't figured out
how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld
fix this on my end is to prefix all my module names with my package name
(seems redundant, of course). Something like 'Base' becomes 'MyAppBase'.
And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Max_Howell · February 3, 2016, 11:16pm

Hi Jason,

module-name collision is something that keeps me up at night. I intend to solve it as properly as possible.

This will involve a proper proposal for swift proper down the line, probably involving namespacing in some form.

For now, you can either cross your fingers or fork the project that has the collision and change the module name.

···

On Feb 1, 2016, at 5:41 PM, Jason Lee via swift-users <swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Jason_Lee · February 2, 2016, 3:50am

Hmm, ok, so I wasn't too far off. I guess this still is along the lines of
the Obj-C way of namespacing. Sorta.. I'm going to look into this more on
the swift package project and in the mean time, I'll use the relevant
project name prefix in the module name. Thanks!

···

On Mon, Feb 1, 2016 at 5:53 PM, Erica Sadun <erica@ericasadun.com> wrote:

This is a good reason why package names should be clear and specific,
avoiding common phrases and terms that will overlap.
A proven way to avoid such issues is to namespace your packages in some
way, e.g. prefer SadunStringUtilities vs SwiftString.

At this time there is no built-in way that I know of how to deal with
module name collisions. So let me speculate about what
a solution might look like. (Skip to the next message if this doesn't
interest.) Having a reverse domain name as
part of the Package declaration syntax maybe could address part of the
issue, for example:

import PackageDescription

let package = Package(
name: "SwiftString"
origin: "com.sadun"
)

and in the case of name conflicts use:

import com.sadun.SwiftString
import com.LeeJason.SwiftString

with all the annoying resolution that might involve in disambiguating
symbols. I could also
see some kind of package alias being needed if this problem got too bad,
e.g.

packagealias Sadun = com.sadun.SwiftString
packagealias LeeJ = com.lLeeJason.SwiftString

let x = LeeJ.countStringItems(someString)

but I don't know how Swift would disambiguate, for example, two packages
that both created
public extensions on String both being imported into the same file, and
both offering conflicting, say, properties.

-- Erica

On Feb 1, 2016, at 6:41 PM, Jason Lee via swift-users < > swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought
over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package
and everything is working well for me. However, when I got this conflict
today, I was thinking this will be a problem going forward. I'm sure it's
been solved already by the package manager team, but I haven't figured out
how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld
fix this on my end is to prefix all my module names with my package name
(seems redundant, of course). Something like 'Base' becomes 'MyAppBase'.
And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Jason_Lee · February 3, 2016, 11:20pm

Hey Max,

I decided to go the longer name route. This has solved my issue - for now. I will keep my eye open for the proposal, thanks!

···

On Feb 3, 2016, at 3:16 PM, Max Howell <max.howell@apple.com> wrote:

Hi Jason,

module-name collision is something that keeps me up at night. I intend to solve it as properly as possible.

This will involve a proper proposal for swift proper down the line, probably involving namespacing in some form.

For now, you can either cross your fingers or fork the project that has the collision and change the module name.

On Feb 1, 2016, at 5:41 PM, Jason Lee via swift-users <swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Max_Howell · February 3, 2016, 11:24pm

Haha, forgive my overuse of “proper”. Blimey.

···

Hi Jason,

module-name collision is something that keeps me up at night. I intend to solve it as properly as possible.

This will involve a proper proposal for swift proper down the line, probably involving namespacing in some form.

For now, you can either cross your fingers or fork the project that has the collision and change the module name.

On Feb 1, 2016, at 5:41 PM, Jason Lee via swift-users <swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Kostiantyn_Koval · February 4, 2016, 2:21pm

Hi Max and Jason,

I just faced same problem.
The origin URL + Version tag uniquely identifies the package. Maybe they could be used as a part of the namespace?
Looking forward for the awesomely proper proposal, I trust you :)

Kostiantyn

···

On 04 Feb 2016, at 00:24, Max Howell via swift-users <swift-users@swift.org> wrote:

Haha, forgive my overuse of “proper”. Blimey.

Hi Jason,

module-name collision is something that keeps me up at night. I intend to solve it as properly as possible.

This will involve a proper proposal for swift proper down the line, probably involving namespacing in some form.

For now, you can either cross your fingers or fork the project that has the collision and change the module name.

On Feb 1, 2016, at 5:41 PM, Jason Lee via swift-users <swift-users@swift.org> wrote:

Today I introduced a dependency on another project's package with brought over a module name that conflicted with one he modules in my project.

Currently my project has multiple modules (and executables) in the package and everything is working well for me. However, when I got this conflict today, I was thinking this will be a problem going forward. I'm sure it's been solved already by the package manager team, but I haven't figured out how to do this from the docs yet.

An example:
Package 'A' has a module named 'Base'
My package also has a module named 'Base'

When I build, I get a circular ref error now. One way I was thinking I cld fix this on my end is to prefix all my module names with my package name (seems redundant, of course). Something like 'Base' becomes 'MyAppBase'. And my imports could look like so:

import Foundation
import Base
import MyAppBase

Any thoughts on this? Thx.

- jason

Sent from my iPhone
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

fortmarek · August 23, 2019, 8:58am

Is this something that has been looked into since then? I stumbled on this problem and could not find any mention about this specific problem somewhere else (but maybe I just did not search well enough).

SDGGiesbrecht · August 23, 2019, 7:18pm

No, this has not been solved yet. There have simply been to many other higher priorities. Prefixing module names is still the recommended workaround. Even the package manager itself has added prefixes to some of its module names in response to collisions reported by client packages.

nthana · March 19, 2020, 11:33pm

It is almost always impossible for a module creator to create a 100% unique module name beforehand. It could lead to the very long qualified name like in java packages:
For example: com.company.division.module1.ClassA

So, I think the longer name is not the elegant solution.

The better solution is to introduce a module renaming semantic (need a Swift proposal). A module consumer (another module or program) should be able to rename/alias any used modules at will, to void collision and/or to make simpler module name.

BigSur · March 20, 2020, 12:52pm

maybe should add import ... as *** support, which can solve this annoying problem.