[swift-build-dev] Hello SPM

[orta therox]

Thinking about this a bit further, performing an automated transition from CocoaPods -> SPM would be feasible given all the metadata is kept in a file, but you’d probably end up breaking carthage support for those libraries. It would also need to update the Xcode projects that may be connected to the source files, which I think would turn into a bit more trouble. Likely could be scripted with the xcodeproj gem though.

-- 

[A.]	    Orta Therox

> w/ Artsy <http://artsy.net/>CocoaPods <http://cocoapods.org/> / CocoaDocs <http://cocoadocs.org/> / GIFs.app <https://itunes.apple.com/us/app/gifs/id961850017?l=en&mt=12>
> @orta <http://twitter.com/orta> / orta.github.com <http://orta.github.com/>
> Artsy is totally hiring iOS Devs <https://artsy.net/job/mobile-engineer> ATM

> On 18 Dec 2015, at 09:16, orta therox <orta.therox at gmail.com> wrote:
> 
> Interesting, so this is feasible, once a pod is downloaded a then Podspec can be ran against it to get access to all of the files. I think an app that could read the Podspec json  and perform some transformation is feasible for most swift pods.
> 
> We’ve already got tools for converting a CocoaPods project to work with the Package.swift <https://github.com/neonichu/schoutedenapus> which you can take some inspiration from.
> 
> -- 
> 
> [A.]	    Orta Therox
> 
>> w/ Artsy <http://artsy.net/>CocoaPods <http://cocoapods.org/> / CocoaDocs <http://cocoadocs.org/> / GIFs.app <https://itunes.apple.com/us/app/gifs/id961850017?l=en&mt=12>
>> @orta <http://twitter.com/orta> / orta.github.com <http://orta.github.com/>
>> Artsy is totally hiring iOS Devs <https://artsy.net/job/mobile-engineer> ATM
> 
>> On 12 Dec 2015, at 12:10, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>> 
>> Circling back on this...
>> 
>>> On Dec 7, 2015, at 10:23 AM, orta therox via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>>> 
>>> 
>>>> On Dec 7, 2015, at 12:30 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>>>> 
>>>> Ok, great! Do you have existing infrastructure for analysis of those libraries? Would it be easy to write a tool to, e.g., count #s and types of libraries? Or create a summary of source layout styles?
>>> 
>>> I have a local machine with a download of every pod, from about 3 months ago. I can probably script this sort of thing, happy to take this one to direct mail if you have an idea of what you want.
>>> 
>>> Given that paths are, generally speaking, added in the Podspec, this can also be generated from the CocoaPods/Specs repo itself too. 
>> 
>> The high level question we would want to answer would be "how much work is it for people to conform to convention X". I could envision trying to automate that by taking the corpus of pods, applying some amount of automated transformations based on the known or proposed conventions and the Podspec, and then seeing if the project builds. If it wasn't too much work to build such a system then it could be invaluable in vetting convention proposals, but I'm not currently familiar enough with the ecosystem to know if this is viable or not.
>> 
>> If you think it is, that is totally something I would consider taking off list if/when I had some time to hack on it...
>> 
>>  - Daniel
>> 
>>> 
>>> _______________________________________________
>>> 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/20151218/4cef18b0/attachment.html>