[swift-build-dev] [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Rick Ballard]

> Proposal link:
>>  https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md

> On Mar 9, 2017, at 3:02 PM, Karl Wagner <razielim at gmail.com> wrote:
> 
>> On 9 Mar 2017, at 23:48, Karl Wagner <karl.swift at springsup.com <mailto:karl.swift at springsup.com>> wrote:
>> 
>>> On 9 Mar 2017, at 23:32, Rick Ballard <rballard at apple.com <mailto:rballard at apple.com>> wrote:
>>> 
>>>> On Mar 9, 2017, at 2:30 PM, Karl Wagner <razielim at gmail.com <mailto:razielim at gmail.com>> wrote:
>>> 
>>>>> * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
>>>> 
>>>> Not really. The package manifest API has lots of serious deficiencies and this proposal shuffles a couple of names around. Not sure it’s really worth the hassle, to be honest. It’s certainly very far from a “redesign”!
>>> 
>>> 
>>> Would you mind expanding on the other deficiencies that you see in this API?
>> 
>> I think they’re rather well-known:
>> 
>> - No support for resources; means no test resources (!), framework or application bundles.
>> - System package API is confusing, doesn’t account for OSX system libraries (“.tbd” files you see in Xcode’s “Link Libraries” panel).
>> - Source trees are exclude-only with no ability to selectively *include* other trees.
>> - Every package must have an independent source control repository. Even if it’s just redirecting to a system library (of which you can only sometimes really control the version).
>> - (Related) It would be nice if we could refer to independent modules within the same repository, who have their own Package.swift detailing their dependencies (like a “sub-package”). This can be helpful when developing modular applications or, as mentioned, when importing some external libraries from the system or another package manager.
>> 
>> - Package manager doesn’t resolve dependencies between files in the same module. You have to resolve it yourself and name the files alphabetically (this may be a bug rather than a missing feature, but I couldn’t find anything in the source which sorted the compiler inputs...)
> 
> I mean — not to be too negative. The package manager is very cool and I’m looking forward to the day when it works for more projects.
> 
> My point was that there are lots of large gaps in the current model, and personally I’d rather we rolled those all together in a “Package.swift v2” rather than making frequent source-breaking changes for cosmetic enhancements. Anything which is additive is fine, but frequent renaming gets annoying.


The point of this proposal is to do a one-time clean-up and standardization of existing API. We indeed have a lot of new API we also need to add, including things you mention above, but those are intentionally out of scope for this proposal; instead, each of those additions should have its own proposal and discussion. Getting this clean-up out of the way now of course means that those new APIs will have a clear set of API design standards to follow when they're added. We are not expecting to rename these APIs again in the future, so this won't be a "frequent" change.

So setting aside the things that we should add in the future, if you don't think it's a good idea to clean up the existing API, that would be feedback we can discuss here. It sounds like you're saying that the hassle of existing packages needing to revise their API use when they adopt Swift 4 is not worth the benefits that this proposal brings – consistency, clarity, flexibility, extensibility, language guidelines compliance, etc. I respectfully disagree, but if you have some more details on why this is going to cause a problem to do, or why living with the existing API's problems moving forward isn't a problem, I'd be happy to discuss that. More specifically, if there are changes to the *existing* API (which don't add significant new functionality) that this proposal does make which you disagree with, or which it doesn't make that you think should happen, this would be the time to discuss that.

Thanks,

	- Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170309/630d6516/attachment.html>