Drop native extension

[fabiopelosin]

Ratio

The Xcodeproj native extension has some important drawbacks:

• Makes installing CocoaPods much more complex that what it should be
• Makes continuous integration difficult (a huge amount of dev time has been spent on fixing Travis, because we are using the mac workers for what they have not been designed to do)

Proposal

Xcodeproj could:

reading

• Use a tool like plutil to convert the project.pbxproj file to JSON/XML
• Read that from Xcodeproj

writing

• Save the project as JSON/XML in a temporary file
• use plutil to convert it to to an XML plist

Benefits

• Without the native extension the installation of CocoaPods and Xcodeproj would be much simpler and less brittle
• We could switch all the CI to Ruby workers. With this approach we would not test the conversion of the plist via the plutil tool. However once setup this is unlikely to break and we can still test it locally during development. To me this is an acceptable trade off because it would free a considerable amount of development resources.

[alloy]

I don’t think this is such a big issue, but, more importantly, moving away from our own implementation would mean we can never preserve UUIDs etc. So this is a no from me.

[alloy]

The only alternative I see is to implement a ASCII plist parser ourselves in pure Ruby with e.g. Ragel.

[fabiopelosin]

I don’t think this is such a big issue

For me it is, for example the Travis builds on the mac workers are erring out again, requiting at least 1 man/hour to fix them.

moving away from our own implementation would mean we can never preserve UUIDs etc

The JSON serialisation would contain the same information of the plist so there would be not problems of the UUIDs (which are just a number under the UUID key). No?

@kylef comment on slack made me thing of another alternative approach. As we need ASCII plist only for reading, we could:

• touch the file with the plutil similarly to what we do with the Xcodeproj.
• use a plist Ruby library for reading and serialising

[alloy]

Can you do a simple benchmark of the cost of shelling out and converting twice?

[alloy]

The JSON serialisation would contain the same information of the plist so there would be not problems of the UUIDs (which are just a number under the UUID key). No?

I dunno why, but for some reason I assumed that plutil would dismiss those as not being a semantic part of the document.

[alloy]

use a plist Ruby library for reading and serialising

For this we should use the CFPropertyList gem which comes pre-installed on OS X.

[fabiopelosin]

Now we are talking again 😄

Before implementing it I have only two observations:

• Shelling out is generally not expensive and we do it many times in CocoaPods
• plutil seems pretty fast

$ time plutil -convert json project.pbxproj -o Data.json -r
plutil -convert json project.pbxproj -o Data.json -r  0.00s user 0.00s system 92% cpu 0.006 total

medium size project

Implementing it should be reasonable simple so if I get the green light I will do an initial pull request where a more appropriate benchmarking can be performed.

[alloy]

I think it’s better to convert to a XML plist, as JSON is not a real plist format. This way we can just use the CFPropertyList gem for everything and if Xcode ever moves away from ASCII plist to XML plist then it will be simple to move over.

Implementing it should be reasonable simple so if I get the green light I will do an initial pull request where a more appropriate benchmarking can be performed.

Ok, go for it :)

One thing that should be properly tested is preserving unicode characters, for which we encoded XML entities atm.

[fabiopelosin]

Also any suggestion to replace Xcodeproj.generate_uuid?

[alloy]

There’s:

• https://github.com/sporkmonger/uuidtools
• https://github.com/assaf/uuid

The latter has a dependency graph of two extra runtime dependencies (afaik), those two are by Ara T. Howard, so those will be small and good. Still, you should compare if they both guarantee to make truly unique UUIDs, the size of the code base, and possibly if it has built-in functions to format the UUIDs to Xcode’s requirement while keeping the unique requirement.

[fabiopelosin]

Closed by #168