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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
