[swift-build-dev] Package "Spec" changes -- reviewable/separable?

[Rick Ballard]

Hi Brian,

Stability and both backwards- and forwards-compatibility will become increasingly important for SwiftPM as our ecosystem grows. At the same time, SwiftPM is still a young product, and we need the flexibility to evolve it to meet the needs of its user community and make sure that we're laying a high-quality foundation for years to come. In terms of lifecycle, SwiftPM 3 is probably roughly where Swift 1 was – which is not to say that we expect SwiftPM to see the same level of source changes that Swift 2 and 3 had, but we will likely need some. I would like us to revamp the API to conform to modern Swift standards for SwiftPM 4, and there are a number of new features to add which will involve new PackageDescription API. We'll need a good version compatibility story to prevent any such changes from inflicting significant pain on the existing package ecosystem.

Some of the contributors are going to be drafting a proposal soon for how to handle versioning in SwiftPM (we at least need some way to let you choose between Swift 3 and Swift 4 syntax) – while we have some manifest versioning features already that went into SwiftPM 3.0, we'll be thinking about what else we might need to do to allow a manifest API rev without breaking the ecosystem.

The testDependencies case was likely a one-off situation in the product's history; it was a broken feature that had never been through evolution review in the first place, wasn't the best way to solve its use case, and unfortunately didn't get removed before SwiftPM 3.0 (the first release of SwiftPM) was released – only immediately thereafter, in SwiftPM 3.0.1. In the future I expect that any change that affects manifest compatibility will have to go through evolution review and approval, including new features in the manifest.

The manifest spec is formalized in the PackageDescription module already. That said, in the future we might consider adding better support for tools which want to interact with manifests – either to parse them (e.g. to support a package index that understands packages) or even to machine-edit them. I don't think we're going to get there this year, but it's a potentially very useful future direction.

Thanks,

	- Rick

> On Jan 11, 2017, at 8:51 AM, Brian Pratt via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> Hey all, 
> 
> I wanted to take the temperature on a thought I've been kicking around: I'd like the Swift "package specification" to take on stability and backwards-compatibility requirements -- something that enables the community to innovate and iterate in this problem-space with more confidence while also proactively preserving the "first-class" nature of SwiftPM as the dominant package declaration format moving forward.
> 
> The primary inspiration for this line of questioning comes from a change from August which removed the (broken) `testDependencies` argument from the Swift `Package` initializer. (https://github.com/apple/swift-package-manager/pull/597 <https://github.com/apple/swift-package-manager/pull/597>) This implementation change in the package manager would cause the package declarations that were using this argument to no longer compile. 
> 
> "No big deal," you may say, "those `testDependencies` weren't ever building in the first place." Well, no, not in SwiftPM, but these kinds of breaking API changes in the package spec could effectively made it impossible for an "alternative" tool like Facebook's alternative to NPM, Yarn (https://www.yarnpkg.com) to exist in the Swift ecosystem -- something that's a community-based take on building and/or resolving these packages without the overhead of dealing with a review and release process that's tied to the language processes.
> 
> What I'd like to propose here in the future is that substantial additions/breaking changes to the package spec / declaration API would go through an evolution-esque proposal/review process. This would help to establish a baseline of use-cases and data-providers that Swift packages themselves would support longer-term, without necessarily saying what the package manager as a whole can do.
> 
> Also, I wonder out loud... how feasible is it to formalize the package spec in code? And distribute those protocols / enums as a separate package or distributable? I understand it may be a low priority at this point, and that's cool, but I'm just curious as to the viability. I feel like just because Swift Package Manager is not able to deal with testDependencies, that does not mean that Swift Packages themselves should have no concept of them, and that kind of conflation of capability of packages to that of the package manager would be solved by separating the two.
> 
> Any thoughts?
> 
> - Brian (@_bppr)
> _______________________________________________
> 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/20170111/83ba6538/attachment.html>