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

[Keith Smiley]

It sounds like we may not get any heads up about any work on that level of
integration:

https://twitter.com/jckarter/status/766072626624073729

Which I guess also brings up the question of whether or not it will be done in
public (which might also be unanswerable).

--
Keith Smiley

On 08/17, T.J. Usiyan via swift-evolution wrote:
> 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
> >

> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution