[swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories
xenadu at gmail.com
Sat Nov 12 23:43:26 CST 2016
> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> Hi all,
> I'm reposting a request for feedback on my proposal for extending SwiftPM to support multiple packages inside one repository (i.e. "monorepo" support, although it is a misnomer in this use case).
> I would like to move this proposal forward so we can start on an implementation, even if we need to refine it over time, but I was hoping to get at least some concrete feedback first.
> - Daniel
It seems like you’re going through contortions to deal with arbitrary directory layouts and some odd consequences fall out of that decision. Not being able to deterministically detect non-unique sub-packages is one.
Why not just require a top-level Package.swift that explicitly specifies the sub-packages? The name for the sub-package should be in the main package manifest. You’d gain the ability to import all the sub-packages in one go; importing the root package without any sub-packages specified automatically imports all sub-packages. This also allows library authors to organize a library into sub-packages later without breakage. Come up with a convention, e.g. a sub-package is in “/subpackageName” but allow overriding that default. That allows reorganization if needed but the convention should work for most libraries.
A top-level Package.swift would also allow immediate detection of non-unique sub-packages, etc. Also if you are using things like git submodules, subtree, or some other mechanism that ends up putting package files in your source tree you don’t automatically re-export that package unless you take explicit action.
I like the idea in general.
More information about the swift-evolution