Run pod repo update trunk
Then pod install
pod Instabug to use HTTP as a source.
The trunk should be updated to the latest "edits" (delete, then re-push) made to Instabug.podspec, I have verified that they are updated on the server here: https://cdn.jsdelivr.net/cocoa/Specs/7/e/c/Instabug/10.0.3/Instabug.podspec.json
pod Instabug is still using git as a source.
CocoaPods : 1.10.0
Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
RubyGems : 3.0.3
Host : Mac OS X 10.15.7 (19H15)
Xcode : 11.7 (11E801a)
Git : git version 2.24.3 (Apple Git-128)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : master - file system
trunk - CDN - https://cdn.cocoapods.org/
Executable Path: /usr/local/bin/pod
cocoapods-deintegrate : 1.0.4
cocoapods-disable-podfile-validations : 0.1.1
cocoapods-generate : 1.6.0
cocoapods-plugins : 1.0.0
cocoapods-search : 1.0.0
cocoapods-stats : 1.1.0
cocoapods-trunk : 1.4.1
cocoapods-try : 1.1.0
platform :ios, '10.0'
use_frameworks!
target 'TestCococapods' do
pod 'Instabug'
end
This is expected. things sync eventually with CDN but not instantly.
Thanks, @dnkoutso
But when do you expect this sync will happen?
@Kmohamed deleting and re-pushing a spec won't be updated locally. My suggestion is to delete ~/.cocoapods/repos/trunk and re-run.
@igor-makarov that would work but it will be really inconvenient for all consumers of the pod to have to do this.
The other solution I have in mind would be falling back to using the original specs git repo by defining it as source in the Podfile.
I’m not sure how CDN _updates_ work, is there a way at all to detect that file has changed (md5?) on the server and needs to be updated?
Worth noting that when I run:
pod install --repo-update --verbose
I get that in the logs (repeated for all versions updated):
CDN: trunk Relative path: Specs/7/e/c/Instabug/10.0.3/Instabug.podspec.json exists! Returning local because checking is only perfomed in
repo update
@yousefhamza you're right, this would be inconvenient for any user that has the old version downloaded.
We do have ETag-based update detection of file modification, however we only use those for index files (e.g. all_pods_versions_4_e_0.txt) and podspecs that are explicitly marked deprecated. If we were to do this for all the files, running pod repo update would take a very long time (in fact, this was the first iteration).
We're making a tradeoff, since we know that pod deletion and re-addition is extremely uncommon.
@igor-makarov so I guess our best option with the current solution is this right?
The other solution I have in mind would be falling back to using the original specs git repo by defining it as source in the Podfile.
I'm thinking of a possible solution to this, what If we _moved_ the entire pod, by deleting Specs/7/e/c/Instabug/ directory and add it again as an all-new pod, so it has a totally new directory e.g. Specs/f/e/f/Instabug/, will that work?
@yousefhamza it's not possible to move the folder to a different shard - the shard is determined by a hash of the pod name.
What I can suggest is delete the relevant pod version (10.0.3) entirely and upload the pod under a new version (e.g. 10.0.4). This would cause CP to ignore the incorrect file.
Thanks, @igor-makarov I think I have an almost complete picture now.
One thing missing, The logs here, maybe signaling that Cocoapods has detected that the file has actually changed but repo update doesn't (but should) implement actually changing the file?
@yousefhamza the message is somewhat inaccurate, because if you run pod repo update you'll see that it isn't one of the files being updated due to reasons explained in https://github.com/CocoaPods/CocoaPods/issues/10229#issuecomment-731994080
Hypothetically, Is it possible to implement something like pod trunk edit that leverages "ETags" like pod trunk deprecate? so .podspecs file are updated from trunk when consumers run pod repo update trunk?
@yousefhamza hypothetically, it is possible - however the large planning and engineering effort for this doesn't seem to be justified as edits to podspecs are infrequent and strongly discouraged (see 'Will I still be able to make modifications to a published podspec' section, except the pull-request part, which was changed to a CLI solution since).
Is there an action item to be taken here? Yes there could be some space for improvement but doesnt seem we will be executing on it.
@dnkoutso @igor-makarov Thank you for your input, no action is pending from your side, I'm closing this issue 🙏
Most helpful comment
@yousefhamza hypothetically, it is possible - however the large planning and engineering effort for this doesn't seem to be justified as edits to podspecs are infrequent and strongly discouraged (see 'Will I still be able to make modifications to a published podspec' section, except the pull-request part, which was changed to a CLI solution since).