This is a great question.

As you note, the module map packages are a little special:

1. They define the support for someone else's project, so the ownership isn't clear.

2. They are also unique in that we hope that for almost all such packages, there is a single "obviously correct" package definition. There shouldn't be many reasons for divergence in implementation once someone has come up with that initial obviously correct solution.

3. Eventually, they may need variations to support platform specific variations in how the library is installed, but fundamentally the package is the same. Users of swiftpm shouldn't need to care about these details to just get access to SQLite.

This means that module map packages, even more than the regular package manager use cases, would benefit from some kind of global index.

We have discussed whether it would make sense to have a global index feature specifically for the module map packages. We are open to the idea, we just don't have anyone driving it right now.

If anyone is interested in driving this effort, I suggest putting together some kind of problem statement, and proposed solution, and either raising it on the swift-build-dev mailing list or if it is well formed enough, going ahead and writing it up as a swift-evolution proposal (https://github.com/apple/swift-evolution/blob/master/process.md).

@mxcl has worked on Homebrew, and Homebrew is centralized and hosted on Github (if I'm not mistaken). Do you know what prevented him from importing his particular experience on this topic to the Swift Package Manager? Does he think there are caveats in the current way Homebrew is centralized?

@ddunbar wrote:

Eventually, they may need variations to support platform specific variations in how the library is installed, but fundamentally the package is the same. Users of swiftpm shouldn't need to care about these details to just get access to SQLite.

The fact that module maps must contain absolute paths is something that may require being fixed first, considering the cross-platform ambition of Swift.

Even before Swift was released as an open source project, regular Xcode users had issues with module maps (see groue/GRDB.swift#2 for an example). It could be alleviated by requiring library users to use the latest Xcode, but this kind of requirement does not hold any longer.

Homebrew made me regret the centralized model. Though having said that I think it would have benefits here since there is really only one correct module map.

Not specializing the behavior for these packages is better for the ecosystem, it remains flexible and consistent.

It would be easy for someone to step up and make an organization that becomes the go-to place for system module packages. I hope the community will answer that call.

If we insisted on a single index then the benefits of decentralization would not be accessible, but if we encourage the community to provide an index while still not treating these package types differently the community has the best of both worlds.

The absolute-path problem is somewhat mitigated by SE-0063.