SSWG 'minimum requirements' to require no existing clashes

Server Pitches
1

Pitch: Add identifier uniqueness criteria to SSWG minimum requirements

As per its charter, the SSWG tries to create a "create a robust, healthy ecosystem for server application development with Swift". Wikipedia has the following to say about an ecosystem:

An ecosystem is a community of living organisms in conjunction with the nonliving components of their environment, interacting as a system.

My interpretation in a software context of this would include that many different components need to be able to interact as a system. In other words, it should be possible to combine pretty much any (SwiftPM) package into an application which is 'a system'.

However, Swift and SwiftPM both have certain restrictions regarding names which can stop two packages being able to coexist in one application. Namely, at least the following must be unique across a whole application:

  • all module names
  • the package basename (swift-nio in https://github.com/apple/swift-nio.git)
  • the pacakge name (the name: String in Package.swift, also swift-nio for SwiftNIO)

Currently, the only requirement on uniqueness that the SSWG requires is

  • Name (must be unique within SSWG)

Besides this being not precise enough, I strongly believe the SSWG should add the following to the minimum requirements:

A package must ensure that at the time it submits the proposal to the SSWG the following uniqueness criteria a met:

  • all module names are unique
  • the package basename is unique
  • the package name: String in Package.swift matches the package basename and is unique

The author(s) should make a reasonable effort to ensure that the names are unique, for example by searching github.com & gitlab.com. Archived or very outdated and clearly inactive packages can be ignored but must be listed as having possibly conflicting identifiers.
Also, for the health of the ecosystem, authors should try to prevent future name clashes to a reasonable degree. For example, even if still available, a package should abstain from naming a module or a type just Connection because of the likelihood of clashes in the future.

Notes: I previously started a discussion thread for the wider issues. This pitch is not as wide-ranging as the discussion thread and tries to merely address the immediate, worst issues that we would face if we ignored module/identifier clashes.

Please let me know your thoughts on this. If people are generally happy, I'd proceed with a slightly more detailed proposal.

2

I think this is a sensible initial proposal that should get consensus from most of the community. We can try to hash out the specifics of long term evolution of project names later on, but we should call out the clash risks now.

1 Like
3

  1. Excellent pitch (I do so love it when someone is on key :laughing:) - I see no obvious barrier to adopting this and I definitely think that should happen ASAP.

  2. I imagine module names are going to be the real pain point here; there are so many "obvious" names that it can be difficult to ensure uniqueness in even a relatively small sample set. A future pitch building on this one may want to go into some specifics of how to choose good names that will neither conflict with existing ones, nor carry a high risk of setting up future contributions for conflicts of their own.

4

Thanks @graskind & @lukasa!

100% agreed. To not delay the adoption of the immediately (IMHO) required changes that this pitch addresses, I thought it might be a good idea to start with just this.

5

Definitely concur there. I imagine a robust approach for module naming will need some significant thought and discussion, and that takes time.

6

Proposal sounds good, though would have thought it was common sense :slight_smile: Perhaps best to call it out explicitly like this though :+1:

Also good to keep out any specifics about naming schemes from this wording; that's up to the people to figure out and not something that can be specced out up front here.

+1

7

This seems sensible to me. It's important that we are able to evolve the SSWG process and requirements in a timely way - they are not carved on blocks of stone.

This does raise a meta-issue about how such changes should be managed. I'm totally fine with pitches like this whether they come from SSWG members or the broader community, in fact I think it's good to do so. But we shouldn't rule out the possibility of the SSWG making changes unilaterally if deemed necessary, just like the Core Team have changed the main evolution process in the past.

We should also try and avoid lots of process discussions and focus on code :slight_smile:

1 Like
8

change management: https://github.com/swift-server/sswg/blob/master/process/incubation.md#change-management

9

adding clarifying text to the min requirements makes sense. that said, as @graskind pointed out, modules names are going to be very tough to deal with without a more substantial adoption of module name conventions across the server ecosystem, and any ecosystem that uses swift-pm packages really. even if folks make best effort to ensure they have no conflicting module names at pitch/proposal time, this wont scale and will not survive the evolution of those packages. in that sense we are dealing with the symptoms not the problem.

so in summary, +1 on adding some clarifying text, but lets kick off a discussions about:

  1. modules name conventions
  2. swift-pm uniqueness requirements for git repo base name and packages name
1 Like
10

FYI, this was announced yesterday. Might be worth considering.

1 Like
11

Slowly catching up on bookmarked threads, this hasn't been shipped yet, right? I skimmed the Proposal section and looks like this is the same as before.

As a community member, seems like a good idea :+1: to codify this as a requirement :tada:

12

It hasn't shipped yet, largely because I haven't found the time to write a proposal yet :slight_smile:.

1 Like