SE-0201: Package Manager Local Dependencies

Evolution Proposal Reviews
#1

Hello Swift community,

The review of SE-0201 “Package Manager Local Dependencies" begins now and runs through March 29, 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

8 Likes
Package Manager Local Dependencies
#2

+1. Other package managers have this feature, and it is useful.

One use case the proposal does not mention is a library including an example app that uses it. (Siesta uses CocoaPods’s path: feature to do exactly that.)

Two questions:

The local package must be declared in the root package or in other local dependencies. This means, it is not possible to depend on a regular versioned dependency that declares a local package dependency.

It seems like this contradicts Motivation number 2, “Some package authors prefer to keep their packages in a single repository.” Shouldn’t it be possible for some public package to include in a subdirectory some not yet published package that is still a separate package? Does that break something else?

A local package dependency will override any regular dependency in the package graph that has the same package name.

What’s the rationale for this not being an error?

1 Like
#3

I avoided mentioning that in the proposal because some authors like to use the URL and version in the examples to avoid confusing beginners but yep, it is useful for example packages.

I don’t think there are contradiction with the reason mentioned for point 2 in the proposal. I think you’re talking about private package sort of thing, which will probably be solved by a multi-package repository feature. Allowing published packages to include unpublished packages is dangerous and we definitely don’t want to allow that. It’ll be easy for people to break package graphs if they use a path that only works for them.

There is no reason to make this an error. This feature is aimed for package developers and not dependency consumers. If you have a local dependency in your package graph, you know about it because you had to clone or create by hand.

#4

Yes, that is what I’m talking about. If multi-package repositories need to be a separate feature, that’s fine — and I grant that the motivation for them is narrow given that a package may already contain multiple modules.

#5

For me, like dev pods in Cocoapods, this is hugely important as there is a non trivial amount of developers out there dogfooding themselves with the same libraries they give out to third parties and do constant development and debugging on them.

2 Likes
#6

+1

This would be very helpful for the development of new packages.

Also this would allow the use of prebuilt packages on a system right? So I can build and install a package at a known location and then use it without the source code being present.

#7

Nope, SwiftPM doesn’t support prebuilt packages. That’ll be a separate feature.

#8

+1 To this, seems like a fairly straightforward feature.

1 Like
#9

+1 This is really important for larger projects with components that are being developed in parallel. This can’t land soon enough!

1 Like
#10

+1. As I stated in the pitch phase I would prefer the following syntax:

public static func package(localPath: String) -> Package.Dependency
public static func package(url: String, from version: Version) -> Package.Dependency
public static func package(url: String, from version: Version, localPath: Bool) -> Package.Dependency

The last version would be equivalent to a package with two dependencies (one repository-like dependency and the preferred local one), so this:

dependencies: [
    .package(url: "https://github.com/pvieito/PythonKit", .branch("master"), localPath: "../PythonKit")
],

Would be equivalent to this:

dependencies: [
    .package(url: "https://github.com/pvieito/PythonKit", .branch("master")),
    .package(localPath: "../PythonKit")
],
#11
#12

This proposal is really about the use case of having a local dependency that is only available in that way. The package manager already has the edit functionality for overriding git-based dependencies with a local copy. I also think that we shouldn’t introduce ambiguity at the manifest level.

Regarding the name of the path parameter: a path is always local by definition, otherwise it would be a URL.

#13

Well, the proposal states:

  • A local package dependency will override any regular dependency in the package graph that has the same package name.

So it clearly allows the creation of packages with local/git dependencies:

dependencies: [
    .package(url: "https://github.com/pvieito/PythonKit", .branch("master")),
    .package(path: "../PythonKit")
],

I think a lot of package maintainers would find this useful and it seems an alternative to the Workspace proposal.

1 Like
#14

Thanks for pointing this out.

This indeed works, but as an override not a fallback. We also have a bug to warn about multiple dependency declarations SR-7334.

I still think adding this kind of workflow behaviour is out of scope for the current local dependency proposal. It might make sense to discuss it as part of what should be done for the use cases the workspace proposal has brought up.

#15

Oh, I see. I was thinking the repo package would work as a fallback. In that case I totally agree with your consideration to leave the discussion to the workspace proposal. Thanks!

#17

The review of SE-0201: Package Manager Local Dependencies ran from March 23…29. Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!

  • Boris
    Review Manager
3 Likes
[Accepted] SE-0201: Package Manager Local Dependencies
Terms of Service

Privacy Policy

Cookie Policy