SE-0226: Package Manager Target Based Dependency Resolution


(Boris Buegling) #1

Hello Swift community,

The review of SE-0226 “Package Manager Target Based Dependency Resolution" begins now and runs through August 28, 2018.

Reviews are an important part of the Swift evolution process. All reviews should be made in this thread on the Swift forums or, if you would like to keep your feedback private, directly in email to me as the review manager.

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available on the Swift Evolution website.

As always, thank you for participating in Swift Evolution.

Boris Buegling
Review Manager


Draft Proposal: Target Based Dependency Resolution
(orta) #2

I don't have too much to add, but I feel like it's worth adding dev dependencies a unique concept. Yes you have to learn how it works, but the abstraction is cheap in comparison to the value you get in encouraging more people to use swiftpm to ship their dev-tooling instead of globally installed home-brew + etc.


#3

EDIT: I clearly misunderstood the proposal. I'm a huge +1 on this and am excited to see it. Been waiting for this feature since SwiftPM was announced!


(Boris Buegling) #5

It should not be necessary to explicitly declare development dependencies once we have this feature. You can declare your development dependencies just like your regular ones, as clients of your package would only build the dependencies needed by whichever products they depend on.


(Boris Buegling) #6

Introducing a new API would also require a new tools version, though, so that would still be required for your proposed solution.

Can you elaborate a bit more on what you mean by a target using "all" dependencies? That's not the case today, either, each target must declare its dependencies on individual products from the dependencies.


(Boris Buegling) #7

The idea is that SwiftPM doesn't need development dependencies to be explicitly declared, because it has more information available about the build due to product dependencies defining linkage. If a dependency is only needed for development or testing, none of the targets exported via products would depend on them, so it is already clear that they do not need to be built. Explicitly declaring them as development dependency would just be duplication of that information.


(Goffredo Marocchi) #8

How do you handle a dependency downloaded from a remote repo (say public or private remote cocoapods repo to make an example) vs the same repo downloaded locally and edited as part of developing an app using it (think of developing libraries, meant to work as remote dependencies, as well as developing the app using the in the same project)? Taking CocoaPods’s dev pods and regular pods setup as reference.


(Boris Buegling) #9

I'm not sure how that relates to the proposal at hand, as it is only about the set of dependencies to resolve and build, not about the locations they are coming from, can you elaborate?

Generally speaking, SwiftPM allows local dependencies in the root package, similar to CocoaPods' development Pods feature. There's also edit mode for temporarily overriding a dependency with a locally checked out copy.


(Jeremy David Giesbrecht) #10

+1 exactly as proposed.

I know of at least one package product I use that would get an estimated 90% reduction in the clean build time for free, and the extra resolution it does now has nothing to do with either “development” or “test” dependencies.

To rephrase @NeoNacho’s answer even more clearly, do you realize that every dependency will get all the benefits of a “development dependency” by default and without any thought on the developer’s part? Everything is basically a “development dependency” until it is manually hooked up to a product. You don’t have to even think about it anymore, because it just works—automatically, all on its own.

Is your concern that it is too non‐obvious how development dependencies should be declared, so that people might avoid declaring them at all because they are unaware of the behind‐the‐scenes optimization? Then maybe it would be worth being specifically called out in the documentation, even though it needs no dedicated API. Something like, “Because dependencies are not retrieved unless they are actually needed, you can declare dependencies that are only needed during development, and they will be completely ignored by client packages as long as they are unreachable from any product.”


(Georgios Moschovitis) #11

+1

I really like this simple and comprehensive solution! This will eliminate one of my pain-points with SPM.


(Rex) #12
  • What is your evaluation of the proposal?
    This is great +1

  • Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
    Yes

  • Does this proposal fit well with the feel and direction of Swift?
    Yes, it’s a simple solution to a problem that’s handled for the user in an expected manner.

  • If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
    N/a

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
    Read the proposal and the comments - seems clear and straight forward.


(Yonas Kolb) #13

+1. Elegant solution to the problem

Once question I have is how are dependencies which point to a product name that is different to the package name handled, or Packages which have multiple library products.

For example the Swift PM package itself has a Utility product. How will that be targeted?


(Jeremy David Giesbrecht) #14

Proposal:

The products declared in the target dependencies will need to provide their package name unless the package and product have the same name. SwiftPM will diagnose the invalid product declarations and emit an error.

This does not affect the top‐level package. $ swift resolve, etc. will still handle all targets of the top package. (It will not cause any problems for Mint. :wink:)

It only affects the dependency tree below that. i.e. If the SwiftPM product had 100 dependencies to resolve, but Utility only had one dependency, and your Mint package only referenced the Utility product, using $ swift build on the Mint package would not bother to resolve SwiftPM’s 100 dependencies, and only resolve Utility’s single dependency, drastically speeding things up.


(Boris Buegling) #15

There will be a new way to specify both the product name as well as the package:

.product(name: "Nimble", package: "TestUtilities")

There's a mention of this in the detailed design section of the proposal.


[Accepted] SE-0226 Package Manager Target Based Dependency Resolution
(Boris Buegling) #16

The review of SE-0226 “Package Manager Target Based Dependency Resolution" ran from August 21…28. Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!

Boris
Review Manager