SwiftPM: Adding development package as a dependency
- Proposal: SE-NNNN
- Author(s): Ankit Aggarwal <https://github.com/aciidb0mb3r>
- Status: *Awaiting review*
- Review manager: TBD
I propose to enable SwiftPM to use a package that is still under
development as a dependency for another package during testing and
During development of libraries, developers commonly want to try out their
module package as a dependency. This emulates the typical library use-case
and is currently not possible in SwiftPM without first checking in and
tagging that library. These extra steps, while reasonable for an
already-built package, are an unnecessary burden for a package that remains
Forcing the user to modify the library package inside Packages to continue
development or continuously reclone the package after recommiting and
retagging strain the process of building the library in the first place.
Under this proposal, the *root* package will be allowed to specify a
DevPackage dependency. This dependency will *not *clone the package inside
Packages/ or require the dependency to be under version control. This will
free the developer to continue iterative testing, expansion, and
enhancements without being tied to the current dependency system.
This approach limits DevPackage dependencies to local file systems. Remote
repositories cannot be used with this keyword.
The following example demonstrates what a manifest file would look like. In
this example, the DevPackage is specified using a local path and the
majorVersion is used as is for this DevPackage.
let package = Package(
.DevPackage(localPath: "../MyAwesomeLibrary", majorVersion: 1),
Under this design:
- DevPackage is limited strictly to the root package. The manifest of
any dependency containing a DevPackage will fail to build.
- A DevPackage is not copied inside Packages/ and does not require
- SwiftPM uses the DevPackage's source directory for building,
permitting in-place development on the local file system.
- SwiftPM disallows non-local DevPackage sources. To use a remote
package, the developer must first clone a package and then specify the
- Version numbers are specified for DevPackage entries within the
- Should the DevPackage version not be selected after resolving the
dependency graph, the build will succeed with a warning.
Impact on existing code
This proposal does not impact existing code.
I propose two possible alternatives to this problem:
1. Create a executable target within the library package for development
2. Use XCTest to test the library.
Both alternate approaches permit testing a library module but they will not
simulate a full SwiftPM package.
Thanks to Erica Sadun <https://github.com/erica> for inputs.