← Back to Upcase

Cocoapods and broken parsing


(Geoff Harcourt) #1

Question for @gfontenot and others:

I’m having a problem trying to update dependencies with Cocoapods. I updated to version 0.35.0 as it asked me to do, and now whenever I try to run pod install, I get this message:

[!] ERROR: Parsing unable to continue due to parsing error:
contained in the file located at /Users/geoff/cortex-projects/cortex-ios/Podfile.lock
PODS:
  - ZeroPush (2.0.3)

DEPENDENCIES:
  - ZeroPush

SPEC CHECKSUMS:
  ZeroPush: 1251bdeecbf0d70e2fdf85a7c968f886f82cc57a

COCOAPODS: 0.32.1

If I downgrade to 0.32.1 it works fine. I get the same problem if I run pod update.

I read the Cocoapods instructions regarding their git repository corruption and their proposed workaround here:
http://blog.cocoapods.org/Repairing-Our-Broken-Specs-Repository/, but none of the steps they described fixed the issue for me.

If I delete all my local cocoapods configuration (so ~/.cocoapods and all the cocoapods-related gems) and do fresh installs and pod setup, I can get 0.32.1 to work, but not 0.35.0. 0.35.0 gives me an error about bad specs that refers me to the blog post I linked to above.

Are other iOS developers having this problem?


(Gordon Fontenot) #2

I haven’t seen this, but have you tried blowing away the Podfile.lock entirely and re-installing? It’s possible that @smileykeith might be able to help, too.


(Geoff Harcourt) #3

Hey @gfontenot, thanks for getting back quickly!

I did try that. Deleting Podfile.lock led to an error about Manifest.lock, deleting that as well led back to the original Yaml parsing error.

If I delete everything and try to do a fresh development envrionment setup with pod setup with version 0.35.0, I get the error about Cocoapods’ git repo corruption troubles, but the steps to solve don’t get rid of the error.

I’m fine with locking myself on 0.32.1 if there’s no negative consequences, but that doesn’t seem like a good strategy going forward. @smileykeith, if you have any ideas, please let me know. I’m experienced with Ruby, but not so much with iOS.


(Keith Smiley) #4

Without diving too much into this, this looks like an encoding issue. Your best bet for fixing that would be opening the affected files, at least your Podfile.lock, and making sure it’s written as UTF-8.

Assuming that is the issue this would also show why reinstalling things as you did didn’t change anything. In reference to that Git issue, as long as you have cloned the repo after the fix everything is fine. The issue was users who had existing repos could no longer pull the newest version.

As far as locking yourself to a specific version of CocoaPods I highly recommend against this. Until CocoaPods hits 1.0 changes can be made to any part of the process that would break with your older version of the tool. The easiest example is the specs repo. The specs repo has a file specifying the minimum and maximum compatible versions of CocoaPods. As this repo is updated each time you run pod install, any day now that minimum version could be bumped and then 0.32.1 wouldn’t work anymore. It is our intention that you always stay up to date.


(Geoff Harcourt) #5

Hey @smileykeith, thanks for the info.

The file appears to be saved as us-ascii rather than utf-8. When I delete it, pod install regenerates another file with the wrong encoding. I’m trying to figure out if there’s something about my environment that could be causing the encoding to be bad. The same thing is happening with my CocoaPods-version.yml file, where the encoding appears to be wrong.


(Geoff Harcourt) #6

(update) I think that I was interpreting the character set, not the encoding, and my files are in UTF-8. I’m unsure of what to do now, given the advice not to lock to an older version that works on my machine.


(Geoff Harcourt) #7

I uninstalled every gem from my Ruby installation and reinstalled Cocoapods from scratch successfully. I filed an issue on Cocoapods about the issue, but I have too many gems to easily figure out what other gem could be interfering with the setup. Thanks to @gfontenot and @smileykeith for the direction.