<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">> Proposal link:<br class="">>> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md</a><br class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 9, 2017, at 3:02 PM, Karl Wagner <razielim@gmail.com> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 9 Mar 2017, at 23:48, Karl Wagner <<a href="mailto:karl.swift@springsup.com" class="">karl.swift@springsup.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 9 Mar 2017, at 23:32, Rick Ballard <<a href="mailto:rballard@apple.com" class="">rballard@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">On Mar 9, 2017, at 2:30 PM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</blockquote></div><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">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”!</div></div></blockquote></div><div class=""><br class=""></div><div class="">Would you mind expanding on the other deficiencies that you see in this API?</div></div></div></blockquote></div><br class=""><div class="">I think they’re rather well-known:</div><div class=""><br class=""></div><div class="">- No support for resources; means no test resources (!), framework or application bundles.</div><div class="">- System package API is confusing, doesn’t account for OSX system libraries (“.tbd” files you see in Xcode’s “Link Libraries” panel).</div><div class="">- Source trees are exclude-only with no ability to selectively *include* other trees.</div><div class="">- 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).</div><div class="">- (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.</div><div class=""><br class=""></div><div class="">- 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...)</div></div></div></blockquote></div><br class=""><div class="">I mean — not to be too negative. The package manager <i class="">is</i> very cool and I’m looking forward to the day when it works for more projects.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick</div><div><br class=""></div></body></html>