[Second review] SE-0386: `package` access modifier

[taylorswift]

my observation having participated extensively in the original review thread, was that median reception to the proposal was mixed to negative.

having watched the steady march of various “package keyword” PRs getting merged into apple/swift over the past month, i was quite concerned that the language workgroup was simply going to ignore all feedback and forge ahead anyway. but i am relieved that the workgroup is taking the need to partition modules within a package seriously, and that the proposal now includes a means for excluding individual targets from the global “package” group. this is a major step forward.

@John_McCall

We also asked the authors to simultaneously consider the ability to divide packages into multiple groups. In response, the authors have added a group: argument to SPM targets which allows them to be excluded from the default package group. This argument could be extended to allow targets to be placed in named groups, but the authors have left that as a future direction because it's unclear whether this is the right way to express that structure to SPM.

unfortunately, i think that simply excluding individual targets is not enough, we need to be able to add excluded targets to a different, named “package” group, otherwise this feature is effectively unavailable to the second or third, etc. nucleus within a versioned package distribution. and in the short term, this puts pressure on packages to split up into multiple subpackages, which is really really bad, because packages are like countries: once you split them up it’s almost impossible to put them back together again, since now you have stable versioning and module aliasing to think about.

this is already outlined as a “future direction” in the proposal text:

The group setting per target in Swift Package Manager allows a target to opt out of a package boundary, but if there is a need for creating multi-groups within a package, the setting could be expanded to allow that by introducing a .named(GROUP_ID) option, where GROUP_ID is a unique identifier for a specific group the target belongs to.

enum Group {
  case package
  case excluded
  case named(String)
}

For example, the new option could be specified in a target setting in a manifest like so:

  .target(name: "Game", dependencies: ["Engine"], group: .named("Core"))

i think this is a perfectly sensible design, that would completely fulfill the multinuclear use case, and should (must?) be incorporated into the proposal itself.