I've just started using the Yarn package manager and I downloaded a starter Ionic 2 project.
In this project, we have a lot of help from scripts that compile, minify, lint and bundle our code. All of this is provided by ionic-app-scripts, which has several dependencies which it uses to run commands.
The problem is when I use Yarn to install, the node_modules/.bin/ folder does not contain all the necessary executables, like tslint, which is a dependency of ionic-app-scripts, so it is not directly in my package.json.
The result is that when I use Yarn, ionic-app-scripts doesn't work because it expects that the .bin folder contains a tslint executable!
What can I do? Are the ionic-app-scripts's definitions a problem?
[note]: npm install works, but Yarn is much faster!
This is a known issue, and there's a pull request with more information.
In short, if you want to fix this now, you'll have to explicitly include the packages from which you need binaries in your dependencies.
I had this issue but a different solution.
The solution was from this ticket https://github.com/yarnpkg/yarn/issues/992#issuecomment-318996260
... my workaround is going to file manager, right click on /node_modules main folder, selecting properties, and check-uncheck "read-only". You can do it also using attrib in command line. Then you retry installation and it works.
Here is the original github issue, support sugested to open a thread here for more public support.
I'm using xcode 6.4.
$ pod --version
0.38.2
My Podfile:
platform :ios, '8.0'
use_frameworks!
target 'Turnt' do
pod 'Starscream'
pod 'Alamofire', '~> 1.3'
end
I met similar problem, too. I couldn't figure out why and soon I lost patience so just ignored the error and clicked "run" directly. The error actually disappeared and "Build Succeeded" was shown!
There are a few other things you can try:
Verify xcodebuild version
Make sure your xcodebuild version also set to 6.4.
Clean All
You certainly want to try clean all in the project. Sometimes that will reset the issue.
Wipe DerivedData and Xcode Cache
Another thing that could be causing the problem is that you may need to wipe your DerivedData folder along with your Xcode cache.
echo "Removing DerivedData and Xcode Cache"
rm -rf ~/Library/Developer/Xcode/DerivedData
rm -rf ~/Library/Caches/com.apple.dt.Xcode
Give those a whirl and I'll update my answer accordingly. Best of luck!
I met the same question and by
Product->clean then Product->build fixed it
The fix for me was changing the platform version in my Podfile to the same version I was building for in Xcode. Then run pod install again. Derp.
Example: platform :ios, '11.2'
For me, none of the above answers worked.
Something I did terribly wrong was setting a flag in Other Swift Flags in the Build Settings. Which override cocoapods custom flags.
It shows an error something like this in that case.
Pod installation complete! There are 16 dependencies from the Podfile and 29 total pods installed.
[!] The `***** [Debug]` target overrides the `OTHER_SWIFT_FLAGS` build setting defined in
`Pods/Target Support Files/Pods-MishiPay/Pods-MishiPay.debug.xcconfig'. This can lead
to problems with the CocoaPods installation
- Use the `$(inherited)` flag, or
- Remove the build settings from the target.
So Instead of removing my other custom flags. I added one more flag $(inherited) after this everything worked fine.
$(inherited) inherits all the custom flags defined by cocoapods
This issue was already reported on Github: https://github.com/Alamofire/Alamofire/issues/441
Follow the following steps
Product -> Clean
Restart Xcode
Rebuild the project
Might have allowed permission to access the keychain
Good Luck and Happy Coding
it's a Xcode bug with Alamofire. Just keep rebuilding the app and cleaning it. After that restart, Xcode and the problem should go away.
Hope that helps,
In my case, I forget to add dependency for all targets. I got the issue only while Unit testing, later I recognised that I missed to add it in .pod file for test target.
target 'SujanTests' do
pod 'Alamofire', '~> 3.7'
end
I'm unable to build a project that uses CocoaPods. I get the following errors:
diff: /../Podfile.lock: No such file or directory
diff: Manifest.lock: No such file or directory error:
The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.`
$ pod install seems to work fine and adds a Pods Project to my Workspace. I've tried $ pod update but this doesn't help.
It seems that PODS_ROOT is not being set.
Podfile:
platform :ios, '6.0'
workspace 'Example.xcworkspace'
xcodeproj 'example/Example.xcodeproj'
pod 'TestFlightSDK', '~> 1.3.0-beta.5'
pod 'TestFlightLogger', '~> 0.0.2'
pod 'CocoaLumberjack', '~> 1.6.2'
pod 'Reachability', '~> 3.1.0'
pod 'SBJson', '~> 3.2'
pod 'MKMapViewZoom', '~> 1.0.0'
I had a similar problem when I did major changes to my Podfile. My solution was to remove the workspace file and run pod install again:
rm -rf MyProject.xcworkspace
pod install
TLDR: This is most likely a bug with Xcode and closing and reopening the project is usually the simplest fix. Assuming everything else is configured properly.
I occasionally get the same error when deleting the Pods directory and then running pod install.
Everything appears correct in the project info:
However, when I go to the target's User-Defined Build Settings, the PODS_ROOT entry is either entirely missing or is empty for one or more configurations. Which causes the following error on build:
The simplest fix is to close the project in Xcode and reopen it.
If you go to the target's Build Settings and filter on All, you will now see the PODS_ROOT entry with no errors:
It should now build with no errors.
Note: Even Cocoa Pods' official AFNetworking iOS Example has this problem, which leads me to believe that it is a bug with Xcode.
An alternative fix is to manually change the configuration to None, then back to its original value:
Go to the target's Build Settings and make sure the value of PODS_ROOT equals ${SRCROOT}/Pods in "User-Defined" section.
update: a podfile.lock is necessary and should not be ignored by version control, it keeps track of the versions of libraries installed at a certain pod install. (It's similar to gemfile.lock and composer.lock for rails and php dependency management, respectively). To learn more please read the docs. Credit goes to cbowns.
In my case, what I did was that I was doing some house cleaning for my project (ie branching out the integration tests as a git submodule.. removing duplicate files etc).. and pushed the final result to a git remote repo.. all the clients who cloned my repo suffered from the above error. Inspired by Hlung's comment above, I realized that there were some dangling pod scripts that were attempting to run against some non-existent files. So I went to my target build phase, and deleted all the remaining phases that had anything to do with cocoa pods (and Hlung's comment he suggests deleting Copy Pods Manifest.lock and copy pod resources.. mine were named different maybe b/c I'm using Xcode 5.. the point being is to delete those dangling build phases)..
So it seems that CocoaPods didn't set the Configurations for my Project. They need to be based on the Pods.xcconfig which is found in the Pods/Target Support Files/Pods. To get this to work I had to do the following:
Drag this file into my Xcode Project in Xcode, choosing not to copy.
Now there is a reference in our project, we can set the configurations:
I then had another build error which may or may not have been related. The path to the shell script defined in the Copy Pods Resources was incorrect.
"${SRCROOT}/Pods/Pods-resources.sh"
Resolved incorrectly. It seemed that SRCROOT was adding an extra dir that didn't exist into the path. So I hard coded the path to the Project folder.
This allowed me to build.
Why is it that so many things that are supposed to save you time end up eating it up?
Note: Please see #abood's answer for explanation.
I have a similar issue this is what worked:
In Xcode:
Clean
Delete Derived Data in Xcode/Window/Organizer/Project/Your Project
Pod directory (it contains config files, delete files not just references!)
Removed all references to the pod config files for every target in Project/Configurations (debug/release)
Removed "Targets/Build Phases/Copy Pods Resources" from all Targets
Removed "Targets/Build Settings/User-Defined/PODS_ROOT" from all Targets
Quit Xcode
In your project directory:
rm -rf Pods
(Optional) rm -rf YourProject.xcworkspace
rm -rf Podfile.lock
pod install
Open YourProject.xcworkspace in Xcode
I got rid of the same problem by doing following steps:
Xcode->Product->Clean Build Folder (hold alt key on Product to see it)
Open Xcode->Window->Organizer and select Projects tab. Then find your project and delete derived data of the project.
Simply resolved by doing the following:
(sudo) gem install cocoapods
pod install
clean and build
it seems the problem was caused by one of our team members having a more recent cocoapods gem installation.
open .xcodeproj file in sublime text
remove these two lines, if you have clean pods folders, i mean if you got the errors above after you removed pods folder
Had the same issue saying
/Pods/Pods-resources.sh: No such file or directory
even after files etc related to pods were removed.
Got rid of it by going to target->Build phases and then removing the build phase "Copy Pod Resources".
I had the same problem recently. I have tried every possible advice, nothing except this plugin has worked for me:
https://github.com/kylef/cocoapods-deintegrate
After the cleaning up of the current cocoapods integration, what's left to be deleted are Podfile, Podfile.lock and the .xcworkspace. Then just install all over again.
I hope I will help someone with this.
This issue got it solved.
Select Target of your Project
Select Build Settings
Open User-Defined drop-down list
Change value of key PODS_ROOT to ${SRCROOT}/Pods
I think it has a bug here.
For me, I delete Pods folder and Podfile.lock and do the pod install again to solve the problem.
This message is ignoring..:(
It wasn't very intuitive. I went to the base project settings and then I hardcoded paths to my pod.lock and pod.manifest under Check Pods Manifest.lock, because they stayed in different folders in fact, so my paths looked like this:
diff "/Users/admin/Desktop/Experimental/projectfolder/Podfile.lock" "/Users/admin/Desktop/Experimental/projectfolder/Pods/Manifest.lock" > /dev/null
if [[ $? != 0 ]] ; then
cat << EOM
error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.
EOM
exit 1
fi
You can try the following. It fixed for me.
install gem install cocoapods-deintegrate
install gem install cocoapods-clean
goto pod deintegrate
pod clean
pod install
The plugins will be remove from cocoapods for your project and will install freshly.
In my case, this was a test target that I removed all the pods from inside my podfile (because I added pods that I later realized I did not need in that target). None of the other solutions here worked for me.
Go to the Build Phases tab in the project settings for the target
that's causing trouble.
Delete the section named "Check Pods Manifest" and "Copy Pods
Resources"
Inside "Link Binary With Libraries" remove libPods-YourTarget.a
In your project settings in the Info tab expand "Configurations" and
set the configuration for the target to None for both debug and
release. (This will fix a couple of missing file warnings)
Delete your project's derived data (Window > Projects > Delete [next
to your project) and restart Xcode. Build / run target.
This made my day!
Deleting the Podfile.lock file in your project folder
Deleting the Pods folder in your project folder
Execute pod install in your project folder
Do a "Clean" in Xcode
Rebuild your project
I had same problem with the my IONIC project, i tried above all solutions but not luck.
If you have same problem still, check weather below settings are present in Build Settings -> User-Defined settings or not
1.PODS_ROOT 2.PODS_PODFILE_DIR_PATH
If not present then add it,
PODS_ROOT = ${SRCROOT}/Pods
PODS_PODFILE_DIR_PATH = ${SRCROOT}/
It will solve problem, solution link
In my case the problem was in the wrong way. solution here http://guides.cocoapods.org/using/troubleshooting.html
If something doesn’t seem to work, first of all ensure that you are
not completely overriding any options set from the Pods.xcconfig file
in your project’s build settings. To add values to options from your
project’s build settings, prepend the value list with $(inherited).
I had this issue.
The way I fixed it was by completely deleting the Pod implementing and re-implementing it. Make sure to delete "Copy Pods Resources" and "Check Pods Manifest.lock" from "Build Phases" on all targets as stated here: How to remove CocoaPods from a project?
For me to get rid of this error, I needed to delete the Pods directory and delete the Podfile.lock file.
In my case I did put Podfile.lock & Manifest.lock in source control, but I forgot to add Pods-Project.debug(release).xcconfig files to source control (by mistakenly adding *.xcconfig to .gitignore), then I got the same compile errors with exactly the same reason, PODS_ROOT is not being set.
So if the goal is that after cloning the repo, the project can immediately build and run, without having CocoaPods installed on the machine, you either add entire Pods directory in source control or add Podfile.lock, Manifest.lock, project's xcconfig files and Pods xcconfig files to source control.
I didn't put the private .xcconfig that merges the build settings with the default CocoaPods configuration to source control.
After spending hours i found the solution go to "Build Phases"
Then "Check Pods Manifest.lock"
Tick "Run Script only when installing"
Thank me later ;)
I have created multiple targets before I ever used pods. Later when I started to compile the other targets I had to add link_with with the list of targets in my Podfile.
I had the same issue. After retracing my recent steps, I found that adding a target declaration for a new target, followed by running pod install, was the cause of the problem:
Resetting my branch and cleaning my project did not work, since Cocoapods modified at least one file that is not under source control. I know this because once I reset the remote branch to a commit before adding the extra target, and re-cloned the repo, the problem no longer existed.
If you have a watchOS target: I found that suddenly, having pods in the watch extension but not in the watch target itself broke things with this same error. The solution was to add the pods to the watch target also.
gem install xcodeproj
may help you.
See pod install fails with abort - New Swift project.
if you added new target after creating Podfile, just delete Podfile, Podfile.lock , Pods folder and workspace
then
init pods ->then put your pods
pod install
After trying the above, I realized I was getting an error on pod install
[!] CocoaPods did not set the base configuration of your project
because your project already has a custom config set.
This was causing the error, because cocoapods was not adding the .xcconfig file to my project.
To solve this I went to the Info tab of my project. Set my Based on Configuration File to None for all schemes and targets. Then re-ran pod install
See this link for more information.
Cocoapods Warning - CocoaPods did not set the base configuration of your project because because your project already has a custom config set
In my case, I accidentally typed an unnecessary dot at the end of the config file which caused this strange problem. Please make sure your config file does not contain any errors!
When I run bundle exec guard everything is kosher, but if I try to run guard I get this:
WARNING: You are using Guard outside of Bundler, this is dangerous and could not work. Using `bundle exec guard` is safer.
Why is this?
From bundler official site:
Run an executable that comes with a gem in your bundle
$ bundle exec rspec spec/models
In some cases, running executables without bundle exec may work, if
the executable happens to be installed in your system and does not
pull in any gems that conflict with your bundle.
However, this is unreliable and is the source of considerable pain.
Even if it looks like it works, it may not work in the future or on
another machine. If you want a way to get a shortcut to gems in your
bundle
$ bundle install --binstubs $ bin/rspec spec/models
The executables installed into bin are scoped to the bundle and will
always work
I'm not sure whether there is anything specific about guard, but in general it's a good practice to run all your gems' executables via bundle exec. May be they just decided to warn developers that running guard without it might cause troubles (e.g. if you have different versions of guard in your system and in Gemfile).