CoreData Model version is incorrectly set/overridden (xcdatamodeld)

[Ashton-W]

From CocoaPods/CocoaPods#1288

I think the new xcdatamodeld support has a bug in how it sets the model version. As it does not keep the version set by xcode originally, and kept in the .xccurrentversion plist file inside the xcdatamodeld/.

64cbdfd#L0R226

The code contains the comment

match Xcode behaviour the last xcdatamodel according to its path is set as the current version.

I don't think that is the correct behaviour if a version has been set already.

[alloy]

Yeah, assuming the last version is the correct version is not always going to be correct. Looking at the code, it’s also not being explicitly sorted, so there is also a chance of the FS not returning them in the expected order.

Is this something you will want to create a patch for?

[Ashton-W]

I don't want to discourage anyone else from patching it, but I'll give it a shot.
I am still new to Ruby, so I may need someone to give it a good look over.

[fabiopelosin]

Indeed a bug. Ouch!

Sent from my iPhone

On 14/ago/2013, at 11:30, Ashton Williams [email protected] wrote:

I don't want to discourage anyone else from patching it, but I'll give it a shot.
I am still new to Ruby, so I may need someone to give it a good look over.

—
Reply to this email directly or view it on GitHub.

[alloy]

@Ashton-W Don’t worry about it. A patch is much appreciated, so we’ll definitely spend some time reviewing it and providing feedback.

[Ashton-W]

Request for comments Ashton-W@8c77d9a

I'm still learning how to run/write the tests, and I haven't worked out how to build a local version of cocoapods. Any tips on that appreciated aswell.

[alloy]

To run the xcodeproj tests, from the checkout run:

$ [sudo] gem install bundle
$ rake bootstrap
$ rake spec

[alloy]

I’m assuming you want to run CocoaPods with these Xcodeproj changes applied? Because the way to do that is different than running CocoaPods itself from HEAD. In this case it’s probably simplest to just install the gem built form the repo:

$ rake gem:install

Or if you need sudo to be able to install gems:

$ rake gem:build
$ sudo gem install xcodeproj-0.9.0.gem

[alloy]

Here’s more information on running CocoaPods itself from a local path, but also using the latest local xcodeproj needs more tweaking, so if it’s really just about these Xcodeproj modifcations, just install the gem like I mentioned in the previous message.

[Ashton-W]

Thanks for the great feedback and tips @alloy!

Request for comments Ashton-W@b724b23

[alloy]

Looks good!

You can take inspiration for the test from here and add it next to that test. To stub the plist, do something like the following:

Xcodeproj.stubs(:read_plist).with('expected/path').returns({ '_XCCurrentVersionName' => 'expected name' })

[Ashton-W]

Request for comments Ashton-W@698e527 Ashton-W@8047884

I have fixed some errors and added a basic test. Next I'll confirm it is working in CocoaPods.

[Ashton-W]

So far I have not been able to fix this issue. I think the cause of this problem may be somewhere other than def new_xcdatamodeld(path, sub_group_path = nil), possibly closer to the project file generation.

I'll keep looking into it.

[Ashton-W]

With a podspec like this:

  s.resources = ['CoreDataPodSample/Classes/*.xcdatamodeld']

and your source xcode project having a xcdatamodeld/.xccurrentversion file like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>_XCCurrentVersionName</key>
    <string>CoreDataPodSample 2.xcdatamodel</string>
</dict>
</plist>

CocoaPods still generates this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict/>
</plist>

Unless I am adding the xcdatamodeld to the podspec incorrectly - I have found no examples or documentation for that.

Edit:

Actually the xccurrentversion file is overwritten by Xcode when it loads the Pods project if the project currentVersion attribute on the xcdatamodeld is empty/missing.

[Ashton-W]

Ok this has turned out to be a bit more complex than first though.

It seems this note from the original CocoaPods issue is the problem

I also noticed that the .xcdatamodeld shows up differently when installed by pod. This may not be the cause.

Left: standalone project. Right: Integrated as a Pod

The .xcdatamodeld shows up like that because it has no children nodes, I have been testing a few different podspecs and none so far have resulted in creating the children nodes correctly. So Xcode opens the project and fixes this problem by stripping the currentVersion and overwriting the .xccurrentversion.

---

Maybe we should revert the recent changes to this until we come up with a working solution? @alloy

[alloy]

Was a bit busy today. I’ll probably have some time on Sunday to read-up on this.

[Ashton-W]

From the specs I have written every things seems to be working on the Xcodeproj side, the current version is read from the .xccurrentversion plist, or the last .xcdatamodel file processed if there is no .xccurrentversion file.

I am unable to find where CocoaPods is handling .xcdatamodeld incorrectly, it may have something to do with it being a 'package', not a file.
I'll take a look at the new bundle code for hints.

[fabiopelosin]

@Ashton-W Can you open a pull request? Moreover can you point out a pod which is not working properly?

[Ashton-W]

I don't know of a pod in the main repo using versioned CoreData models. This has come up in pods I use privately at my company.

I have however mocked up a repo for testing: https://github.com/Ashton-W/CoreDataPodSample

See:
CocoaPods/CocoaPods#1292
CocoaPods/CocoaPods#1288

[alloy]

Ugh, sorry for dropping the ball on this. Thanks for the follow-up, @irrationalfab!

[fabiopelosin]

@Ashton-W I have merged your pull and credited you in the changelogs. The issue was related to the fact that Xcodeproj had an approximative handling of the paths, which needed some love. As CocoaPods in the, implementation of the last version, was passing relative paths, Xcodeproj would attempt to read the paths from the working directory. This has been fixed now.

[fabiopelosin]

@Ashton-W Thanks btw!

[Ashton-W]

Thank you 👍

[dkuhnke]

Great 👍