[swift-build-dev] Draft proposal: Package Manager Product Definitions

Daniel Dunbar daniel_dunbar at apple.com
Fri Nov 18 10:59:56 CST 2016


On Nov 17, 2016, at 10:21 PM, Russ Bishop via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
>> 
>> On Nov 17, 2016, at 1:33 PM, Anders Bertelrud <anders at apple.com> wrote:
>> 
>> Hello Russ,
>> 
>> On 2016-11-17, at 13.01, Russ Bishop <xenadu at gmail.com> wrote:
>>> Did you consider allowing the specification of dependencies as part of the target dependencies? It would be mostly useful for simple leaf packages. If we included a "default" target concept you could omit the name too. 
>>> 
>>> let package = Package(
>>>  name: "MyClientLib",
>>>  targets: [
>>>      Target(name: "MyUtils"),
>>>      Target(name: "MyClientLib", dependencies: [
>>>          .target(name: "MyUtils"),
>>>          .product(name: "Alamofire", package: "Alamofire", url: "https://github.com/Alamofire/Alamofire", majorVersion: 3)
>>>      ])
>>>  ]
>>> )
>> 
>> We didn’t consider this, but I can see the appeal for simple leaf packages.  I’m not sure that the convenience makes up for the additional complexity of allowing the package reference directly in the target dependency, however.  Since we’d still have to support package references on their own, there would be two different ways of referring to a package, which means that if a new way to reference packages is added, we’d have to make that change in two places.
>> 
>> Would there be anything expressible in this way that wouldn’t also be expressible using a separate package reference?
>> 
>> Thanks,
>> 
>> Anders
>> 
> 
> No, it would just be more convenient. Far more people will be creating leaf packages than anything else… by several orders of magnitude. IMHO it might be worth some affordances for that case.

I agree, this is something we should eventually make more convenient in the common case where you only ever reference a package once.

I think that is something we can incrementally add on once we get more of the critical structure in place though, I don't think anything we are doing now precludes that.

 - Daniel

> 
> Russ
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161118/54bb5fda/attachment.html>


More information about the swift-build-dev mailing list