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

Thu Aug 18 14:52:14 CDT 2016

To elaborate on this slightly:

We plan for you to be able to write iOS Swift Packages, but rather than creating a complete iOS build system in SwiftPM, this will likely work by leveraging Xcode's build system. We think that great Xcode integration is a requirement before we will see mass SwiftPM adoption by the iOS developer community. Since Xcode is not part of the open source project, the schedule and specific plans for that work are not public – but there will be work done in the open source project to give SwiftPM a library architecture suitable for allowing it to integrate with IDEs like Xcode.

In the meantime, SwiftPM supports generating an Xcode project from a package, which you can then use to build for iOS if desired (with some additional configuration of the generated project). We're open to pull requests to improve this functionality as well. For now, I would not broadly recommend that iOS developers switch to a SwiftPM-based workflow for their production software using this interim approach.

There are a lot of improvements to make to the workflow and features of Swift packages, and many of those improvements should have an effect on the eventual Xcode integration. Our public focus is on building a solid open source base that can support a thriving Swift package ecosystem for years to come. We're grateful to the developers who are using SwiftPM today and providing us with valuable feedback; much of today's use is to support server-side Swift development. And we're excited to grow SwiftPM into a tool that will meet the needs of our broader developer community!

	- Rick

> On Aug 17, 2016, at 7:43 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> Our stated plans here, and there hasn't been any change, is to leave building for iOS to Xcode. We have (very) limited support for doing that from SwiftPM via generated projects, and it would be nice to see that support deepen. However, there are a lot of limits to that approach and for something better we will need to wait for full Xcode integration. Unfortunately, we don't yet have a much better answer than this one from last year:
> 
> https://lists.swift.org/pipermail/swift-users/2015-December/000052.html <https://lists.swift.org/pipermail/swift-users/2015-December/000052.html>
> 
> The reality is that we have a lot of work to do to make the package manager and its ecosystem a stable base for development... for *any* platform. We think its really important to have that base be solid so that it can grow successfully, which means we are prioritizing features that impact the package syntax, dependency resolution, and workflows. The scope of things we would need to tackle to directly build for iOS is just too long (remote testing, cross-compilation, code signing, entitlements, provisioning profiles) to try to do simultaneously.
> 
> Cheers,
>  - Daniel
> 
> On Aug 17, 2016, at 4:58 PM, T.J. Usiyan <griotspeak at gmail.com <mailto:griotspeak at gmail.com>> 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 <mailto: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 <https://github.com/czechboy0/swiftpm-packages-statistics>, itself powered by a Swift Package.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160818/35e28128/attachment.html>