[swift-build-dev] Swift Package Manager - Support for downloading/installing external dependencies that a Swift Package may have

[Max Howell]

Hi Ricardo,

Respectfully I’d rather you waited, I have a proposal in the works for major changes to the content of Package.swift and this would have quite an impact on this feature.

I will try to get the proposal to the list soon.

If you want to do the PR anyway we will accept it provided it is not executed as a default (requiring a flag marked explicitly as temporary) and that we will remove the flag when the feature is properly implemented and integrated.

> Hello Max, just following up on the previous email. Does the approach described in the previous message fit with the plans and vision for SPM? If it does and our team were to take a first shot at implementing something like it, would our pull request have good chances of getting merged with the SPM repo?
> 
> Regards,
>   Ricardo Olivieri
>   Software Engineer
> 
> 
> From:        Ricardo N Olivieri/Austin/IBM
> To:        Max Howell <max.howell at apple.com>
> Cc:        swift-build-dev at swift.org
> Date:        02/01/2016 09:12 PM
> Subject:        Re: [swift-build-dev] Swift Package Manager - Support for downloading/installing external dependencies that a Swift Package may have
> 
> 
> Thanks Max again for your response.
> 
> I see what you are saying about having SPM fail the build and output suggested commands to install the missing system-packages (as opposed to having SPM perform system-package installations).
> 
> We are still wondering if we could have a solution built into SPM that would not required any manual intervention from a human. For instance, would implementing something like the following be in the plans for SPM (this is somewhat similar to the original option #1 we shared previously)?
> Swift Packages can specify dependencies on other libraries that are not Swift Packages (such as C libraries). The Swift Package Manager could then "parse" this metadata, download the C code for that external dependency (say, from the its GitHub repo), compile it, and make it available to other Swift Packages through the module.modulemap file. The metadata could be part of the Packages.swift file or a new file for specifying dependencies that are not Swift Packages.
> 
> Your thoughts?
> 
> Regards,
>   Ricardo Olivieri
>   Software Engineer
> 
> 
> 
> 
> From:        Max Howell <max.howell at apple.com>
> To:        Ricardo N Olivieri/Austin/IBM at IBMUS
> Cc:        swift-build-dev at swift.org, Samuel Kallner <KALLNER at il.ibm.com>, Daniel Firsht/Austin/IBM at IBMUS, Andrew M Trice/Washington/IBM at IBMUS, Robert F Dickerson/Austin/IBM at IBMUS
> Date:        01/28/2016 01:08 PM
> Subject:        Re: [swift-build-dev] Swift Package Manager - Support for downloading/installing external dependencies that a Swift Package may have
> Sent by:        max.howell at apple.com
> 
> 
> 
> Thanks Max for your answer. To your point, thinking about it more, it's probably not a great idea to have SPM execute arbitrary scripts.
> 
> It is good news to hear that something similar to option #1 could be implemented and that there are plans to provide something as part of SPM that can take of installing/downloading external [non-Swift package] dependencies that a Swift Package may depend on.
> 
> Does providing this functionality in SPM have a high priority? Any other details about the plans for this feature that could be shared at this point?
> 
> High-ish. There are gaping holes in SwiftPM that are currently higher priority.
> 
> This ticket should wait for my up-coming proposal that will improve module-map-packages IMO. Then we can put this in there and implement it at the same time.
> 
> IMO it should work like Homebrew’s caveats. If the build fails it outputs suggested commands to install the missing system-packages, then the user can type those commands in if they so choose.
> 
> 
> 

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