> On Jan 24, 2017, at 8:31 AM, Daniel Dunbar <daniel_dun...@apple.com> wrote: > >> >> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez <ch...@masters3d.com >> <mailto:ch...@masters3d.com>> 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
That is just a directory that it is not named sources. After reading the road map. I think what I am referring to here is something along the line of – Overriding Package Conventions – Support for Top-of-Tree But not quite Multi-package repository because I just want to be to able to have multiple packages in one repo but not necessary have them exposed as individual sub packages. This is the same use case as the above stackoverflow multiple local packages question. > >> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> On Nov 12, 2016, at 9:43 PM, Russ Bishop <xen...@gmail.com >>>> <mailto:xen...@gmail.com>> wrote: >>>> >>>> >>>>> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev >>>>> <swift-build-...@swift.org <mailto: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 >>>>> >>>>> <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 >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
