[swift-evolution] Swift Package Manager 3.0 Project Status

[Daniel Dunbar]

Hi everyone,

The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.


## Release Plan

Our `swift-3.0` branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).

Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!


## Project Status

We have accomplished a lot in the past year, but the package manager still has a long way to go and there are a number of areas where we know there to be significant limitations:

* The current dependency resolution strategy is not able to resolve complex graphs with conflicts. This has not proved to be a major problem so far -- we suspect because of the relative youth of the ecosystem -- but this is an area known to need significant work.

* It can be quite difficult to deploy binaries built with the package manager, and there are little to no controls over some of the necessary parameters (like static versus dynamic linking, or management of linker RPATH values). See SR-648, SR-674, SR-1968, SR-2048.

* We are missing important workflows for a number of typical development scenarios: (1) lock files / version pinning, (2) editable packages (SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring dependencies (SR-679).

* Our documentation needs more work.


## Future Directions

The immediate focus for the package manager is on features and bug fixes which address the issues mentioned above and improve the usability of the tool, but which do not require significant changes to the current overall design (in particular, we would like to defer major changes to the manifest API until we have resolved more of the workflow issues).

Towards that end, the things we are interested in tackling in the short term are:

* Editable packages (SE-0082)
* Improved dependency graph resolution & diagnostics:
  * Fine-grained package dependencies
  * Branch support (SR-666)
  * Version lockfiles/pinning
  * Dependency name collisions
* Stabilizing the manifest API for Swift 4
* Focused improvements to the Xcode project generator (SR-1653, SR-1655, SR-1740, SR-1741).
* Support for managing supported Swift language versions, as this feature develops in the compiler.
* Improvements to build consistency (SR-1708, SR-2182).
* Improvements to documentation (SR-2179, SR-1586).
* Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261, SR-2270, SR-2271).
* Performance

Once we are on a more stable footing, there are many things we could tackle next. Here are some of the areas we are interested in investigating, to see if any of them fit in the scope of Swift 4:

* Evaluating the role for a centralized package index
* Extending the package model to support more use cases (extensible build targets, custom source layouts, more expressive product definition APIs)
* Package metadata such as license and attribution information
* Supporting repositories containing multiple packages
* Support for third-party testing frameworks
* Support for cross-compilation


We hope that gives some picture of where the Swift package manager is headed. It's an exciting time for Swift development, and we can't wait to see what the year holds!

- Daniel

(*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself powered by a Swift Package.