<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2016, at 9:00 AM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">On Aug 29, 2016, at 12:07 AM, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>> wrote:<br class=""><br class="">I completely agree with your original email, and agree the target-access control proposal amounts to a variant of #2.<br class=""><br class="">We definitely need a per-target dependency solution, and if we got one that included some kind of solution for managing the duplicate declaration, that would solve the con you list with #2. That might suggest that one approach here is to add it the list of reasons we should do a per-target dependency proposal.<br class=""><br class="">…<br class=""></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">My leaning here is towards trying to figure out a good approach for #2 first, and see where that leaves us<br class=""></blockquote><br class=""></div><div class="">I’m not up on all the discussion, but that certainly seems to me like the right direction.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 29, 2016, at 10:36 AM, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Aug 29, 2016, at 2:35 AM, Honza Dvorsky <<a href="mailto:jan.dvorsky@me.com" class="">jan.dvorsky@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Not sure if already mentioned, but the issue of duplicated dependencies in targets can be easily handled like this:<div class=""><br class=""></div><div class=""><div class="">import PackageDescription</div><div class=""><br class=""></div><div class="">let sharedDependency: Package.Dependency = .Package(url: "...", majorVersion: 1)</div></div></div></div></blockquote></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">…<br class=""></blockquote></blockquote><blockquote type="cite" class=""><div class=""><div style="font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""> .Target(name: "Second", dependencies: ["First", sharedDependency]),</div></div></div></div></blockquote><div class=""><br class=""></div>I'm not sure that is a syntax we want to support per the long term plans to split the manifest into a "leading package specification" which, while Swift, is a restricted subset we know we can parse into a machine editable form.</div></div></blockquote><br class=""></div><div class="">It’s a tangent, but … doesn’t that defeat the advantage of having the syntax be Swift, namely being able to execute code within the package declaration to eliminate redundancy and conditionally declare things?</div></div></div></blockquote><div><br class=""></div>No, the intent was to support both cases, but to prioritize the leading package specification being able to describe most scenarios. See:</div><div> <a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md" class="">https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The package syntax is already a bit hard on the eyes, and quite finicky. (When do you use “.”? What is the correct order for all those named args?) If it’s going to be a bespoke syntax anyway, I’d vote for abandoning Swift syntax altogether and focusing on readability.</div></div></div></blockquote><div><br class=""></div><div>I am pretty happy with the decision to use Swift, and don't see a reason to abandon it here.</div><div><br class=""></div><div>What I think is true is that we need to revisit exactly how the APIs are spelled to be more consistent with Swift3. That is part of the things we know we need to tackle next. We also hope to eventually be able to automatically help manage the manifest, which I believe will mitigate this problem.</div><div><br class=""></div><div>If you have concrete examples of things you think are finicky or spelled badly, that is worth raising separately and feeding into a discussion of cleaning up the manifest API.</div><div><br class=""></div><div> - Daniel</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">(Apologies if I’m reopening a well-trodden discussion.)</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""></body></html>