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

[Daniel Dunbar]

On Sunday, November 13, 2016, David Hart via swift-build-dev <
swift-build-dev at swift.org> wrote:

> If we're going down the road of KISS, why not require all packages to be
> in direct sub-directories? Is that too constraining?


Yes, I think so. Projects should be able to be in control of their
non-package directory heirarchy I think.


> I've read the proposal and I'm also concerned about the potential
> complexity. But I also like, as Daniel has said, that it allows the naive
> solution - simple subdirectories for each package to work without learning
> a new file syntax.
>
> On a side note, do we really need a "subpackage" argument for the Package
> initializer and not roll everything under "package"?


How would this look?

 - Daniel


> David.
>
> > On 13 Nov 2016, at 06:54, Daniel Dunbar via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >
> >
> >> On Nov 12, 2016, at 9:43 PM, Russ Bishop <xenadu at gmail.com
> <javascript:;>> wrote:
> >>
> >>
> >>> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev <
> swift-build-dev at swift.org <javascript:;>> 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.
> >
> > 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 at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161113/b84e0ff9/attachment.html>