Cocoapods: ERROR | [iOS] file patterns: The `vendored_frameworks` pattern did not match any file.

Created on 31 Mar 2017  Â·  9Comments  Â·  Source: CocoaPods/CocoaPods

Hi,

Im creating a private cocoapod. I have pushed my IOS framework abcd.zip file in a public repo and have pushed the abcd.podspec file in my private repo.

Initially when my 's.version = '1.0' all works well and Im successfully able to integrate pods in my test app.But the pod integrated has old framework and not the latest one i pushed to public repo.

So now, when i update the s.version to 1.0.1 i get the error:- The vendored_frameworks pattern did not match any file.

The reason to update my s.version to 1.0.1 is that i have pushed some changes in the public repo for my framework to be compatible with Swift 3.1 and xcode 8.3. I have also tagged my public repo with tag '1.0.1'.

Please guide.

What did you do?

ℹ Please replace this with what you did.
pod repo push abcdiOS abcd.podspec

What did you expect to happen?

ℹ Please replace this with what you expected to happen.
PodSpec file to be pushed in private repo.

What happened instead?

ℹ Please replace this with of what happened instead.
Validating spec
-> abcd (1.0.1)
- ERROR | [iOS] file patterns: The vendored_frameworks pattern did not match any file.

[!] The abcd.podspec specification does not validate.

[!] Unable to read the license file /private/var/folders/rc/mhv3qqjx0tx2fqkvp3dbggtc0000gq/T/CocoaPods/Lint/Pods/SwyftSDK/LICENSE for the spec abcd (1.0.1)

[!] Unable to read the license file /private/var/folders/rc/mhv3qqjx0tx2fqkvp3dbggtc0000gq/T/CocoaPods/Lint/Pods/SwyftSDK/LICENSE for the spec abcd (1.0.1)

CocoaPods Environment

ℹ Please replace this with the output of pod env.

Stack

   CocoaPods : 1.1.1
        Ruby : ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]
    RubyGems : 2.6.8
        Host : Mac OS X 10.12.4 (16E195)
       Xcode : 8.3 (8E162)
         Git : git version 2.6.3
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib
Repositories : SwyftSDKiOS - https://github.com/Monotype/cs-swyft-sdk-ios.git @ 05b9bd3bc38a62768cb67c16ebdf50ad6833b7e3

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-clean       : 0.0.1
cocoapods-deintegrate : 1.0.1
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.1.2
cocoapods-try         : 1.1.0

All 9 comments

Without the podspec, it's hard to debug.

This looks like a great example of a question that you should ask on StackOverflow - there is an active tag CocoaPods where people can help out with questions like this. We try to keep the CocoaPods issues focused only on bug reports for the tool, and for upcoming feature requests. Which this doesn't look like.

Hi,

Somehow i have resolved the issue and now concluded the main cause of the issue.

When in put my framework in zip file and host on public repo it gives me the error:- The vendored_frameworks pattern did not match any file.

But when i put my framework in an unzipped folder it is able to update the podspec version and fetch latest commit from public repo.

Would you mind checking the issue in pod tool for zip folders pod spec file doesn't allow the s.version to be updated?

Hm... I'm having the same issue. My podspec's source is set to a ZIP file hosted on BitBucket and the vedored_frameworks won't match my included framework :(

Did you had any luck with this?

Same issue - and I've had it for a long time. I think it has to do with how the folders/files are zipped/unzipped but I've never been able to track the issue down. For the record, I often zip things up using the Mac OSX (10.12) right click -> Compress option. I've tried compressing the file by itself and also compressing a folder that contains the file and can't figure it out. I do this a lot and it seems like this issue only comes up occasionally...

@dnkoutso maybe we can reopen this issue for consideration?

It's probably because the the files you zip, try to unzip them does it recreate a new folder and so all your globs fail to resolve?

Yeah that's always what I thought the problem was and have tried in the past to also add the containing folder name to the vendored_frameworks field. I just tried a .tar.gz and got it to work...

I think some log visibility when using pod spec lint --verbose into what exactly is unzipped (and kept, because it seems like there are things in the /Users/{USERNAME}/Library/Caches/CocoaPods/Pods/External/{PODNAME}/{random_hash} path that is printed as the place things are copied from later that are missing from the original download) would help in these scenarios. It's pretty much just guesswork otherwise...

To get going again, I used tar -cvzf folder_name.tar.gz folder_name/* to compress a folder that contains the .framework for my pod, uploaded that to s3, and then just used the name of the .framework in vendored_frameworks (no prefixed folder name in the podfile). It seems like that's what I did before also, though, but I did various other things in between to try and delete any local caches Cocoapods had for this pod to try and test with a clean slate, so who knows what the possible reasons are for these weird issues that pop up occasionally...

@ekilah, thank you _so much_ for your last comment--it solved the problem I've been working on for 2.5 days! I thought, from the rather sparse documentation about them, that the vendored_frameworks path had to be a local path, but it appears to be a path in the remote source.

Depending on where your zip is coming from you might be able to use :flatten on the :source declaration to get rid of the extra folder. Some extra info here

I've just been manually zipping up my frameworks. I have a somewhat convoluted situation, because our repo is private and contains iOS and tvOS frameworks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hmistry picture hmistry  Â·  3Comments

pronebird picture pronebird  Â·  3Comments

steffendsommer picture steffendsommer  Â·  3Comments

soleares picture soleares  Â·  3Comments

5SMNOONMS5 picture 5SMNOONMS5  Â·  3Comments