|
| 1 | +# Package Manager Local Dependencies |
| 2 | + |
| 3 | +* Proposal: [SE-0201](0201-package-manager-local-dependencies.md) |
| 4 | +* Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r) |
| 5 | +* Review Manager: [Boris Bügling](https://github.com/neonichu) |
| 6 | +* Status: **Active Review (March 22...29, 2018)** |
| 7 | + |
| 8 | +## Introduction |
| 9 | + |
| 10 | +This proposal adds a new API in `PackageDescription` to support declaring |
| 11 | +dependency on a package using its path on disk instead of the git URL. |
| 12 | + |
| 13 | +## Motivation |
| 14 | + |
| 15 | +There are two primary motivations for this proposal: |
| 16 | + |
| 17 | +1. Reduce friction in bringing up a set of packages. |
| 18 | + |
| 19 | + Currently, there is a lot of friction in setting up a new set of interconnected |
| 20 | +packages. The packages must be in a git repository and the package author needs |
| 21 | +to run the `swift package edit` command for each dependency to develop them in tandem. |
| 22 | + |
| 23 | +2. Some package authors prefer to keep their packages in a single repository. |
| 24 | + This could be because of several reasons, for e.g.: |
| 25 | + |
| 26 | + * The packages are in very early design phase and are not ready to be published |
| 27 | + in their own repository yet. |
| 28 | + * The author has a set of loosely related packages which they may or may not |
| 29 | + want to publish as a separate repository in future. |
| 30 | + |
| 31 | +## Proposed solution |
| 32 | + |
| 33 | +We propose to add the following API in the `PackageDescription` module: |
| 34 | + |
| 35 | +```swift |
| 36 | +extension Package.Dependency { |
| 37 | + public static func package(path: String) -> Package.Dependency |
| 38 | +} |
| 39 | +``` |
| 40 | + |
| 41 | +* This API will only be available if the tools version of the manifest is |
| 42 | + greater than or equal to the Swift version this proposal is implemented in. |
| 43 | + |
| 44 | +* The value of `path` must be a valid absolute or relative path string. |
| 45 | + |
| 46 | +* The package at `path` must be a valid Swift package. |
| 47 | + |
| 48 | +* The local package will be used as-is and the package manager will not try to |
| 49 | + perform any git operation on the package. |
| 50 | + |
| 51 | +* The local package must be declared in the root package or in other local |
| 52 | + dependencies. This means, it is not possible to depend on a regular versioned |
| 53 | + dependency that declares a local package dependency. |
| 54 | + |
| 55 | +* A local package dependency will override any regular dependency in the package |
| 56 | + graph that has the same package name. |
| 57 | + |
| 58 | +* A local dependency will not be recorded in the `Package.resolved` file and |
| 59 | + if it overrides a dependency in the package graph, any existing entry will be |
| 60 | + removed. This is similar to the edit mode behaviour. |
| 61 | + |
| 62 | +* The package manager will not allow using the edit feature on local dependencies. |
| 63 | + |
| 64 | +## Impact on existing packages |
| 65 | + |
| 66 | +None. |
| 67 | + |
| 68 | +## Alternatives considered |
| 69 | + |
| 70 | +We considered piggybacking this on the multi-package repository feature, which |
| 71 | +would also allow authors to publish subpackages from a repository. However, we |
| 72 | +think local dependencies is a much simpler feature that stands on its own. |
0 commit comments