[swift-build-dev] [swift-evolution] Swift Package Manager 3.0 Project Status

[T.J. Usiyan]

What are the near term plans–if there are any–for supporting iOS? I made
the mistake of assuming support was a couple months away at most when the
package manager was announced. I plan to port my iOS/Mac frameworks over as
soon as I can.

TJ

On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160817/e053d141/attachment.html>