I'm working in a shared iOS project where we use Cocoapods to handle library imports.
Whenever I run the command pod install, my Podfile.lock is altered:
EXTERNAL SOURCES:
Blabla:
- :path: "./PodsLocal/Blabla"
+ :path: ./PodsLocal/Blabla
MyApp:
- :path: "."
+ :path: .
If I then commit, my colleagues will have to run pod install (since the Podfile.lock changed), which in turn adds the quotes back again.
This means that whenever they push changes I have to run pod install, and whenever I push changes the have to run pod install.
We are all using Cocoapods version 0.39.0 and ruby 2.1.3p242, gem 2.2.2. They are using rvm, while I use rbenv.
Is this a bug? Which one of us have the correct setting?
Keep up the good work!
EDIT:
I started this ticket by writing semicolons instead of quotes, which probably has caused som confusion. I realised it a couple of posts in and changed it.
Please double check that you all are using the same version of psych (gem list | grep psych)
Thanks for your response @segiddins
We all have 2.0.5, but a colleague also has 2.0.13. However, they don't experience problems between each other. It's only between me and them.
No clue then.
I'll need steps to reliably reproduce this to be convinced that this isn't just differences in psych versions being loaded, since thats always been the issue in the past, sorry :(
I understand your concern @segiddins. However, we have a new colleague which has the same problem as me. Can we at least establish what the right/modern/recommended syntax would be? With or without quotes?
Thanks again for answering!
My Podfile looks like FWIW and we don't see problems with it switching, so I'd assume this is correct
BTW, you could try doing it using the Mac app, which hosts its own version of all gems, including the problematic psych gem.
I'm also not seeing any semicolons in that YAML output -- only quotes? Can you check if 1.0 fixes things, by any chance?
Sorry @segiddins , I meant quotes the whole time, not semicolons... My bad!
We will try the 1.0 beta later on, and see if that can fix the issue.
EDIT:
I modified the ticket to say quotes instead of semicolon after this post.
I am also seeing the same thing. When another dev in my team does a pod install the quotes are gone, and when I do it, the quotes are there. I'll check the gem versions tomorrow but cocoapods gem at least is the same (latest) version for both of us.
@tkrajacic what is your ruby, psych and cocoapods version and what is your colleagues version?
I have the latest version of every gem. My colleague had the the latest pod command but he didn't have any gems installed (no cocoapods) and also didn't install via homebrew. So gem list showed only the system default gems, there is no rbenv and he didn't install from source.
I am not in my office the next two weeks, so can't say more for now unfortunately
@tkrajacic Ah ok, thanks. I'll try to find a setup to recreate a diff in Podfile.lock. We're currently 2 developers with quotes and 2 without.
Closing because this just _has_ to be a psych / ruby setup issue. Sorry.
Me and @niltoft. I spent a day trying to create a setup to reproduce the issue, no luck. Ended up with a hacky solution, we sanitize the .lock file from the post install hook.
If folks are still running into this (like I was), I was able to fix this by downgrading to ruby 2.0
Looks like it's caused by a difference in how YAML module quotes string in different ruby versions.
In ruby 2.0.0:
{:path => '../node_modules/react-native'}.to_yaml #=> "---\n:path: ../node_modules/foobar\n"
At some later ruby version, to_yaml will always quote all strings.
E.g. in ruby 2.1.2
{:path => '../node_modules/react-native'}.to_yaml #=> "---\n:path: \"../node_modules/foobar\"\n"
Not sure if this by design or not: but is it not logical that pod install never updates the Podfile.lock if it already exists? We have a similar Podfile.lock change dance when all developers are not on the same version of the cocoapods gem.
try do this..
sudo gem uninstall cocoapodssudo gem install cocoapods -v 1.0.1
Most helpful comment
Not sure if this by design or not: but is it not logical that
pod installnever updates thePodfile.lockif it already exists? We have a similar Podfile.lock change dance when all developers are not on the same version of thecocoapodsgem.