> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez <[email protected]> wrote: > > Hi Daniel, > > I think this is an excellent idea! This would also solve the “local only” > packages problem. > http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager > > <http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager> > > By treating the git repo still as a single package, we can then just allow > local dependencies that live somewhere in the repo. > > let package = Package( > name: “myMainPackage", > dependencies: [ > .Package(url: “./allMyLocalPackages/packageOne/“), // don’t > have to specify version because it is inherited from main package. > .Package(url: “./allMyLocalPackages/packageTwo/“), > .Package(url: “./allMyLocalPackages/packageThree/“), > ] > ) > > > I think this would lower the scope of the proposal and it would address the > issue of being able to split up a mono repo. > > Should I propose this as an alternative or collaborate on the draft that you > have?
I'm not exactly sure what change you are proposing, can you elaborate? What is "allMyLocalPackages" in your email? - Daniel > I have a very specific example where I want to be able to split up a repo so > I can test them together on CI. > https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21 > > <https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21> > > > Thank you. > > >> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Nov 12, 2016, at 9:43 PM, Russ Bishop <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev >>>> <[email protected] <mailto:[email protected]>> 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 >>>> >>>> <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. >> >> Mostly because I am concerned this doesn't scale well to *very* large >> repositories, in which commits to that file would be "contentious" (in the >> lock contention sense, not subject to debate sense). Of course, this >> argument is a little bogus as the current proposal doesn't scale that great >> either since we have to discover the packages (although I believe we can >> probably do a good job of caching this information). >> >> It certainly would simplify the implementation & proposal to have this. >> >> The other reason is it is yet another thing for people to maintain (and >> remember the syntax for). Most repos are small enough that I think the >> current proposal would perform fine and have a tendency to do what people >> might naively expect (even if they didn't really think about why). On the >> other hand, this file is likely to be quite static, so I'm not sure that is >> a very important issue. >> >> I was already on the fence on this, but I hadn't considered the benefits you >> mention of allowing import of the package w/ no sub package specifier to >> mean import of all sub-packages. That tips me a little more towards thinking >> maybe a better proposal is to KISS and require this in some root file >> (whether or not that root file is itself a package manifest or a different >> kind of file is another question, you assume it would be the regular package >> manifest but I don't think it *need* be, and there is some value in not >> having any nesting relationship amongst packages). >> >> - Daniel >> >>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
