First of all, I apologise for bringing this up only now but I believe this is very important for the long-term health ecosystem and it's not too late yet.
What's the issue?
In a given Swift(PM) application, 3 things about a package need to be unique across the whole application:
- it's package basename (for example
- it's package name (
let package = Package(name: "swift-nio", ...)in
- all module names
Arguably, that can lead to tricky issues when combining multiple packages. We realise that SwiftNIO is becoming a dependency of more and more libraries and therefore we want to make your lives easier by defining rules for ourselves on how to name things.
So what is NIO doing to help?
Because all those identifiers (basename, package name, module, and type names) can not be changed without releasing a new public API version we try to make the ones we add predicatable. For SwiftNIO, we have tried to be very careful and we have specified what exactly we will and won't do, and how we namespace new symbols in SwiftNIO's public API declaration.
Basically: Unless we release a new major version, we will only add symbols (in minor version bumps) that have
c_nio* prefixes. All of our modules are and will always remain
CNIO* too. And our packages are
How does this help?
Unless you name your package
swift-nio-* or create modules that start with
CNIO and follow the recommendations NIO's public API declaration there should be very little room that your package is clashing with SwiftNIO today or in the future, so it should remain compatible. That is very important for the ecosystem to work long-term when we have an order of magnitude more packages that depend on each other.
Why am I bringing this up?
The reason I bring this up now is that mostly as part of the SSWG, there are a lot of great new packages being created that all use SwiftNIO and we couldn't be more excited about it. Examples are:
The problem here is that there is a high chance of name collisions in the future because a lot of those packages are either
swift-nio-* or have modules/types called
NIO*. This will basically break everything we try to help you with by setting out rules for ourselves in the public API guidelines. In other words: If everybody names they modules/types
NIO* and their packages
swift-nio-*, then breakages are similarly likely to if we just didn't use our namespaces at all.
I believe that we're solving a real issue here and therefore my proposal would be to sort of claim packages prefixed
swift-nio as well as module/type names starting with
CNIO as SwiftNIO's namespace. I realise that it's very late asking people to rename their packages/modules to something else and it some cases it won't be possible anymore. By all means, if you have released a public version that people are using, please don't worry to change things until at least you release a new major version. For upcoming SSWG packages however I think it would be great to not use
Does that make sense? Is this too much to ask? And what do you think about this?