[swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

[Russ Bishop]

> 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).
>  https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/NNNN-swiftpm-multi-package-repos.md
> 
> 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.
> 
> Thanks,
> - 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.


Russ