[swift-build-dev] Test-only dependencies

[Daniel Dunbar]

> On Aug 29, 2016, at 9:00 AM, Paul Cantrell <cantrell at pobox.com> wrote:
> 
>> On Aug 29, 2016, at 12:07 AM, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>> 
>> I completely agree with your original email, and agree the target-access control proposal amounts to a variant of #2.
>> 
>> 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.
>> 
>> …
>> 
>> My leaning here is towards trying to figure out a good approach for #2 first, and see where that leaves us
> 
> I’m not up on all the discussion, but that certainly seems to me like the right direction.
> 
>> On Aug 29, 2016, at 10:36 AM, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>> 
>>> On Aug 29, 2016, at 2:35 AM, Honza Dvorsky <jan.dvorsky at me.com <mailto:jan.dvorsky at me.com>> wrote:
>>> 
>>> Not sure if already mentioned, but the issue of duplicated dependencies in targets can be easily handled like this:
>>> 
>>> import PackageDescription
>>> 
>>> let sharedDependency: Package.Dependency = .Package(url: "...", majorVersion: 1)
>>> …
>>>         .Target(name: "Second", dependencies: ["First", sharedDependency]),
>> 
>> 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.
> 
> 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?

No, the intent was to support both cases, but to prioritize the leading package specification being able to describe most scenarios. See:
  https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md

> 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.

I am pretty happy with the decision to use Swift, and don't see a reason to abandon it here.

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.

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.

 - Daniel

> (Apologies if I’m reopening a well-trodden discussion.)
> 
> Cheers,
> 
> Paul
> 
> 

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