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

[Brian Pratt]

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) 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170111/f75dba6e/attachment.html>