I am using Cocoapods, and one of the libraries I use is ZUUIRevealController, currently the version is 0.9.6 in Cocoapods, which is not the latest one, if I want to create my own pods for that, what are the steps for doing it?
Thanks!
To update for everyone:
OK, so all the cocoapods are held inside a big specs repository Here. We want to go down to the ZUUIRevealController part of the repo. We can see just the 0.9.6 which is how cocoapods knows what version it is.
So, fork the cocoa pods spec repository and open the folder in SublimeMate Pro. You're going to want to add the next version to this folder, so let's say you were going to use 0.9.7. Make a folder for that and copy it over ZUUIRevealController.podspec from version 0.9.6.
The new podspec will need some changing as it refers to the git tag "v0.9.6" and ideally you want to use 0.9.7. Now I've checked for you, there isn't a 0.9.7 which means you'll have to create an issue asking for a new tag, which someone has already done.
With the new tag in the repo you can move that tag into your podfile. Then in the Specs directory run pod specs lint ZUUIRevealController which will tell you whether your podspec has passed or failed linting. If you don't do this it will be done automatically on your pull request, and it's likely that it will be me telling you how to fix it.
If it passes, you can then commit that change and submit a pull request to the Cocoapods/Specs repo on github.
To update for just you:
in your podspec, you can set the commit that you want to override the normal podfile's commit with ( for example )
pod 'ZUUIRevealController', :git => 'git://github.com/orta/ZUUIRevealController', :commit => 'd4c9d810e0f0d1982472c8d1d5469841b09854ab'
This may require deleting your Pods directory first as it might have cached the url / commit.
Related
How would you use your own fork of Next.js in a project?
I tried using patch-package but the next package gets overridden by Vercel
Also tried releasing to npm but it's pretty difficult since it needs to release to many #next/ packages first
How would you go about this?
Some people frown on this technique, but I've used it in many projects with great success.
tl;dr - fork the repo on git and install directly from git. Works with monorepos by using GitPkg.
Fork the repository you want on git
Clone your new fork: git clone https://github.com/<your-user-name>/<package-name>
Make any changes and push those changes. Take note of the commit hash.
Install the dependency using the following format:
npm install <your-user-name>/<package-name>#<commit-ish>
Important: replace the <commit-ish> with the hash from Step #3 (note: a tag or branch name works too). This step is important as it makes sure you are locked to a specific version.
If you are referencing a monorepo, you can specify the subdir for the particular package you want by using GitPkg.
Continue working like you normally would. As you make changes to the package, you will need to push those changes and repeat Steps #3-4 to get the new changes in your project.
Keeping things up-to-date
To update the package, you will need to merge any new "upstream" changes made by the original author and push those to your forked repository. Then repeat Step #4 above.
Add the original "upstream" remote:
git add upstream https://github.com/vercel/next.js.git
Pull down any changes and merge them - make sure to reference the right branch name:
git fetch upstream
git checkout <main-branch>
git merge upstream/<main-branch>
Resolve any merge conflicts and then push to your fork: git push origin
Repeat step #4 from above for installing the latest changes - make sure to pick a new commit hash or tag in order to get the latest changes.
Folks,
Cocoapods : 0.39.0
FYI I have done enough research and I was able to take care of errors like:
Podfile.lock not found.
.menifest not found
and others while building my project.
Which still seem hack to me but as long as they let me build I dont care.
But one real problem is this :
Pod-resources.sh not found and this one is in the pod directory.
so for sure Its not in my source control as I dont check in pods dir into my project.
I have done more than enough weokspace deletion, podlock deletion, who pods dir deletion and pod install. but this problem is still there.
I am using apptentive which has a resource bundle, which need to be copied to the app binary.
At the moment I have disable Apptentive thru out the project to speed up the development and keep looking for solution.
Links that I have read are follows :
https://github.com/CocoaPods/CocoaPods/issues/2303
is from July 10, 2014 : seem too old to rely on.
CocoaPods Errors on Project Build
Error:"The sandbox is not in sync with the Podfile.lock..." after installing RestKit with cocoapods
The sandbox is not in sync with the Podfile.lock-ios
Error:"The sandbox is not in sync with the Podfile.lock..." after installing RestKit with cocoapods
How I solved my partial problem : delete workspace file, Pods Dir and .lock file. If this can help anybody.
Culprit was the path. It seem how Cocoapods is handling is different than earlier.
What it dont do is updating your project file for Copy Resources phase:
it seems they have update the path and now it has "/Target Support Files/Pods-ProjectName/" in it.
Older path: "${SRCROOT}/Pods/Pods-ProjectName-resources.sh"
New Path: "${SRCROOT}/Pods/Target Support
Files/Pods-projectName/Pods-Project-resources.sh"
So if you are having same errors like me you need to do is :
remove workspace file
remove .podlock file
remove .menifest file
do Pod install
update the path in build phase in xcode project file as shown above.
Now Build the project/workspace
Hope this will save someone's time.
You might have to add a PODS_ROOT user-defined build setting, as described here.
I am using GitHubObjectiveCGitIgnore
When I go in sourcetree to commit I see :
project.xcworkspace
This file is not ignored using Github .gitignore file.
I am not sure do I need to commit and push this file?
If you're using Cocoapods, I actually find that the answer depends on a few things.
If you just want the project to be compilable and runable "out of the box", then go ahead and check everything in; xcworkspace and all pods.
If there is a pod that you need to modify for some reason and you want to include that change with your project, then check everything in. For instance, I've found bugs that haven't been fixed for one reason or another and it was easier to just fix them myself and check in the pod along with my project rather than wait for the updated pod or integrating the library manually (which is essentially the same result as checking the pod in anyways). Alternatively, fork the repo, push your changes to it, and point your pod to your fork.
If you have no issues with any of the pods and you've verified that everything works with the versions of the pods you've specified, then you don't have to check in the xcworkspace file or pods. Of course, you'll have to run pod install in this case.
There's no hard and fast rule on what to do here. Sometimes it's worth the extra overhead to just check everything in, and sometimes it's not necessary. It depends on what's most convenient for you.
In short yes it should be commited.
I have my xcworkspace file checked in to my repo. If you don't use a workspace it probably isn't needed but as I use Cocoapods this creates a xcworkspace with the original project and the pods project inside of it.
Use a workspace is the correct way on handling multiple project sets/dependencies.
If you have/or plan to have several projects in the workspace (for example sub projects of your project) then you should not add it to .gitignore.
Cocoa pods just adds its own project to the workspace if a workspace exists when you do a pod install.
In general it is safer to include the workspace file in the git commit, even if you exclude pods.
You will have to do a pod install anyway to compile your project so even if you commit a workspace file that already has the cocoa pod project added it wont cause any issues.
I have a simple project and wanted to include a third party library (CocoaLumberjack) using CocoaPods. After creating the simple Podfile I ran pod install in my project directory. Everything worked fine, except I now have untracked files in my project that are marked with question marks in Xcode:
Is this how it's supposed to be? I don't remember having these question marks when I last used CocoaPods in a different project. Shouldn't CocoaPods automatically set up the correct gitignores for the pods?
CocoaPods doesn't do anything with your .gitignore.
I recommend using GitHub's Objective-C .gitignore (at least as a starting point). Alternatively, just make sure you ignore the Pods directory by adding an entry for Pods in your ignore file:
# CocoaPods
Pods
I need to switch from Composer (which is used by Symfony2 by default) to Git submodules.
I thought I could just add the desired submodules to the desired locations, thus overwriting the current version which was installed by Composer.
But when I use git submodule add, it says:
'vendor/twig/twig' already exists in the index
So I tried:
git rm vendor/twig/twig
and tried to add the submodule again, same error.
What am I doing wrong?
I'm founder and ceo of cloudControl. Currently composer does break our image building process because it interferes with the logic we have to detect submodules in some way. The team is aware of this problem and working to fix the underlying issue.
I'm working for cloudControl and we've been lately inquiring into this issue.
Regarding the original problem, you proposed already a right solution for replacing the composer packages by git submodules, it was just a git commands issue. But doing this doesn't make much sense, as long as these git submodules are identical to the Composer packages and your php code is still hanging on the autoload.php provided by Composer.
We don't process internally Composer yet, their files are just added into the repository and the php code requirements make the rest. However we do process git submodules, so if you want to make a real switch from Composer to Git Submodules, the best option is getting rid of Composer files (vendor folder and composer.* files), adding git submodules wherever you want and handling again the php dependencies . Thus everything should work fine and you'd have switched completely to git submodules.
Native support for Composer is in our future plans.
The problem was that i had to actually delete and git-remove the repository first.
i.e. for twig what i did in the end was:
git rm -r vendor/twig/*
rm -r vendor/twig/*
git add vendor/.
git submodule add git://github.com/fabpot/Twig.git vendor/twig/twig
git submodule add https://github.com/fabpot/Twig-extensions.git vendor/twig/extensions
Now i have twig and twig extensions as a git submodule and can use it in my cloud application.