> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev > <swift-build-...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
