I host a private podspec repo internally, and I would like to use Cocoapods without depending on the public master spec repo. Is there a way to remove dependency on the master spec repo entirely?
The issue is that my company is frozen at cocoapods 0.34.1, and cannot update in time. However, recent changes to the master repo require a min version of 0.35.0. Any time I try to run any pod command, I get the following message.
[!] The "master" repo requires CocoaPods 0.35.0 - (currently using 0.34.1)
I understand what that means, and would like to remove the master repo as a dependency altogether, but it seems like that isn't an option. Any insights?
This created quite the fire drill for us today. We ended up changing our build scripts to run a custom pod install alias, which rolls back the min version in the CocoaPods-version.yml.
alias myPodInstall="sed -i -e 's/min: 0.35.0/min: 0.34.0/' ~/.cocoapods/repos/master/CocoaPods-version.yml; pod install"
Definitely a hack, but it unblocked us as we push for our release. Perhaps this helps others out there in a similar situation.
Related
How to delete one pod manually with Cocoapods in Xcode?
I knew pod deintegrate, I have seen How to remove CocoaPods from a project?
It is too hard for me. Need more details, or a tutorial.
The reason of doing it:
I take part in an old, massive project.There are thousands of warnings there . So I want to maintain a personal version of the project.
When starting to delete one pod ,failed after running pod install
the warnings:
term pod install
Analyzing dependencies
[!] The version of CocoaPods used to generate the lockfile (1.5.0) is higher than the version of the current executable (1.4.0). Incompatibility issues may arise.
Cloning spec repo `z-appplatform-zspecs` from `http://git.zsys.com/AppPlatform/zSpecs.git`
[!] Unable to add a source with url `http://git.zsys.com/AppPlatform/zSpecs.git` named `z-appplatform-zspecs`.
You can try adding it manually in `~/.cocoapods/repos` or via `pod repo add`.
[!] Smart quotes were detected and ignored in your Podfile. To avoid issues in the future, you should not use TextEdit for editing it. If you are not using TextEdit, you should turn off smart quotes in your editor of choice.
The remote repos are of my company's server, I need authorization (secret).
After a lot of communication with my leader, he said "The pods don't need to update. And he can't give me the authorization to remote repo, he will manually do it for me"
Not convenient, with trying a lot to improve a massive project.
At my work, we have a private cocoapods repository that we use to host whitelisted libraries for developers, and I am trying to validate a library I wrote.
Whenever i do a pod spec lint MYPODNAME --verbose, CocoaPods tries to validate my spec against the master repo instead of my private repo.
Is there any way to get around this behavior?
I have tried completely removing the master repo, but it still attempts to validate my pod's dependencies against master
EDIT: This issue seems to describe what I am experiencing.
Answering my own question. You have to manually specify the --sources for what CocoaPods will validate the spec against.
pod spec lint MYPODNAME --verbose --sources=git#<DOMAIN>:<REPO>.git
I've just published a Beta version of a Pod in the Specs Repo, using pod trunk push. I would like to know if is there any way of removing this version Spec from the Spec Repo. I didn't find any way of doing this via the pod command.
CocoaPods now provides a CLI for deleting pods, it can be done with:
pod trunk delete PODNAME VERSION
Original answer:
Removing specs is highly discouraged. If you push a spec intending to remove it later you shouldn't push it in the first place. This is because if any users are using your spec as soon as you remove it their project will break. If this was an accident you can submit a pull request to the specs repo removing your version. Also worth noting after removing this version you can never again push a spec with the same version number.
You can now delete specific versions of a Pod to correct an accidental push.
pod trunk delete PODNAME VERSION
You can also deprecate an entire Pod and all versions
pod trunk deprecate PODNAME
Reference: https://github.com/CocoaPods/cocoapods-trunk/blob/master/CHANGELOG.md#100beta1-2015-12-30
Note that you need to be using pod version 1.0.0.beta.2 or greater. Run pod --version to check. To install the beta, run sudo gem install pod -v 1.0.0.beta.3 (get the latest version from the ChangeLog)
This is what worked for me:
On GitHub, navigate to the main page of the repository.
Under your repository name, click Releases.
On the Releases page, to the right of the release you want to delete, click Edit.
Delete
source
I already did a pod trunk push for a podspec version. Can I push it again and overwrite the existing one?
I tried it but it gives me this error.
$ pod trunk push Parse-iOS-SDK.podspec
Validating podspec
-> Parse-iOS-SDK (1.2.21)
[!] Unable to accept duplicate entry for: Parse-iOS-SDK (1.2.21)
Is there a similar command like git push -f force push it?
Ref:
http://guides.cocoapods.org/making/getting-setup-with-trunk
It is now possible to do this by first deleting the pod, and then re-pushing it:
pod trunk delete NAME VERSION
Then
pod trunk push PODSPEC
There should be a really good reason to do so, however, and the best practice is to never delete versions but instead push new ones (what Keith said).
2017 Edit: You can now delete pods on trunk, see this answer
Previous answer:
You cannot overwrite a spec using trunk. You should just push a new version with your changes. You can also submit a pull request to the specs repo but we recommend just pushing a new version.
I was so excited to get a private CocoaPods repo working. I got v1.0 of my little internal library working with my main app like a charm. Then I added something to the library, committed it, tagged it with v1.1, pushed it up and everything went straight to hell.
No matter what I do, even though my main app reports that my internal library is pointed at 1.1, I keep getting the same code back as 1.0. I'm stumped.
Things I have verified:
My private pods repo has the correct folder structure, and the .podspec files in each folder have the appropriate s.version
Did a file compare of the two podspec files on my internal pods repo and confirmed that the only change to the file was the version number.
Did a git checkout tags/1.1 on the repo with the internal library and confirmed the 1.1 tag contains the appropriate commit.
Confirmed via the BitBucket website the file changes and tag for 1.1 made it there.
I have also tried the following things to resolve it (that I can remember right now) and still got the same code added in the Pod.
Removing the offending pod from the Podfile, running pod update to delete it, re-adding it, then running pod update again.
Clearing ~/Library/Caches/CocoaPods and [ProjectRoot]/Pods and running pod install.
Removing my remote pod repo via pod repo remove [NAME] and then re-adding it under a different name.
Pointing the podspec at :head
Pointing the podspec at the specific commit I wanted.
Pointing the podspec at my local copy of the library.
All this craziness points to some sort of caching issue with git or Xcode, but running CocoaPods in verbose mode doesn't seem to show anything other than super-temporary cache paths that get deleted the second pod update is done.
Anybody got any further suggestions? This is driving me bananas.
Update 1/24: I checked out the code under a seperate username and got some odd behavior:
pod install
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.0)
Installing Google-Mobile-Ads-SDK (6.7.0)
Installing LARSAdController (3.0.3)
Installing UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
[!] From now on use `[App Name].xcworkspace`.
Interesting, I thought, that it grabbed the 1.0 version even though I don't specify any version in the Podfile. So then I ran:
pod update
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.1)
Using Google-Mobile-Ads-SDK (6.7.0)
Using LARSAdController (3.0.3)
Using UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
And the code doesn't change, even though the version number increments. So this points to something I screwed up rather than a caching issue - but if I did, why the hell is it grabbing version 1.0 at all? Any thoughts?
Welp, this was a PEBKAC/not seeing the forest for the trees problem, which I realized when I tried to give up and switch to a git submodule and saw what appeared to be the same issue.
I'd pointed the CocoaPod at /[Project Root]/Library (and was initially looking in there when I tried to move to a git submodule), but when I'd dragged that folder into Xcode in the library project, I'd accidentally left the "Copy Items Into Destination Group's Folder (if needed)" checkbox checked. That created /[Project Root]/[Subfolder]/Library, where all of my changes were actually going. Once I fixed that, surprise surprise, everything worked fine.
So, uh, I guess the lesson here is that if you've gotten this far down the rabbit hole, step back and make sure there's even a rabbit you need to be chasing to begin with.