cocoapods / core

The models used within the CocoaPods gem

CocoaPods Core

The CocoaPods-Core gem provides support to work with the models of CocoaPods. It is intended to be used in place of the CocoaPods gem when the installation of the dependencies is not needed. Therefore, it is suitable for web services.

Provides support for working with the following models:

• Pod::Specification - Podspec Syntax Reference.
• Pod::Podfile - Podfile Syntax Reference.
• Pod::Source - collections of podspec files like the CocoaPods Spec repo.

The gem also provides support for ancillary features like Pod::Specification::Set::Presenter suitable for presetting descriptions of Pods and the Specification::Linter, which ensures the validity of podspec files.

Installation

$ [sudo] gem install cocoapods-core

The cocoapods-core gem requires Ruby 2.6.0 or later.

Collaborate

All CocoaPods development happens on GitHub, there is a repository for CocoaPods and one for the CocoaPods specs. Contributing patches or Pods is really easy and gratifying.

Follow @CocoaPods to get up to date information about what's going on in the CocoaPods world.

License

This gem and CocoaPods are available under the MIT license.

core's Issues

Linting private repo URI fails

PL #77 introduced a bug when linking private specs with sources under [email protected]:cocoapods/EnterpriseKit.git. We are using self-hosted GitLab instance and it's not possible to use HTTP without authentication. Storing credentials or OAuth token does't seem to be good idea.
I'm not sure if it's possible to use https://TOKEN:[email protected]/COMPANY/REPO.git like format in GitLab

As far as I understand putting semicolon after host name violates RFC2396, so we need to find other way to validate URIs here.

[Spec DSL] Add deprecation attribute

I'm sure this has come up in conversation has come up before. It would be nice to have an attribute on a spec like deprecated as a boolean that would alert users when they were installing a deprecated pod. CocoaPods/Specs#8326 The only way people seem to be alerting users of deprecations now is by adding a small line to the summary.

If this was thought of as being too talkative there could be a ignore_deprecations field that could be added to a user's Podfile.

[Linter] Check PodSpecs for unknown keys

As PodSpecs can by loaded by JSON or YAML files it would be useful to highlight any non supported key.

This should be implemented in a dedicated method in https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/linter/analyzer.rb#L6. The implementation could check the Pod::Specification#attributes_hashagainst the Pod::Specification::DSL.attributes. Each attribute agains the Pod::Specification::DSL::Attribute#name which is used as a key for the hash storing them

Replace usage of the term "spermy" with "optimistic".

@alloy said we should remove mentions of ‘spermy’

This will effectively mirror the RubyGems pull request: rubygems/rubygems#124

Podspec can't use utf-8 without lint failure

Ruby uses a magic comment in the first line of the file to specify the encoding of the file. Otherwise ASCII is assumed.

To specify utf8, a comment like this is put into the first line of the source file:

# -*- coding: utf-8 -*-

When running pod lib lint on this, a warning is issued and the lint fails. This is the output:

$ pod lib lint
-> Pixltag (0.1.0)
    - WARN  | Comments placed at the top of the specification must be deleted.

[!] Pixltag did not pass validation.
You can use the `--no-clean` option to inspect any issue.

I don't think this is very helpful. Non-ascii names are impossible to use then.

[Specs] Adopt subject convention

The system under test should be referenced by the sut acronym instead of using different names. This convention is concise and simplifies refactors.

For example @set should be changed to @sut in this line

Linting source of a spec is broken for certain URLs

Looks like #77 was a bad idea.

[10] pry(main)> URI.parse('[email protected]:foo/dfs.git')
URI::InvalidURIError: bad URI(is not URI?): [email protected]:foo/dfs.git
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/uri/common.rb:176:in `split'

[11] pry(main)> URI.parse('/Volumes/myrepo/source code')
URI::InvalidURIError: bad URI(is not URI?): /Volumes/myrepo/source code
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/uri/common.rb:176:in `split'

Remove Pod::Specification::Set::Statistics

This class doesn't belong in Core and for that matter to the command line tool in my opinion. It should be handled by https://github.com/CocoaPods/metrics.cocoapods.org.

Also I'm of the opinion that pod search --stats should be remove in favour of the search provided by cocoapods.org.

Marked as blocked because it requires trunk to be operational.

Using `vendored_frameworks` should automatically set the associated public headers.

Currently when using vendored_frameworks you also have to specify source_files or public_header_files, which is slightly redundant.

[Linter] check frameworks attribute for invalid frameworks

As seen in https://github.com/Marxon13/Specs/commit/8ca38c40a2c8db87ce97b944417425623d18a737

• frameworks
• weak_frameworks
• libraries

A simple regex rule for detecting invalid names, such as with , and spaces etc.

Assumes comments incorrectly

The linter throws a warning when comments need to be removed from this line based on /^\s*#/

The issue with this is podspecs like freexl that injects a ton of #define statements. These are treated as comments and therefore not accepted.

 -> freexl (1.0.0d)
    - WARN  | Comments must be deleted.

One workaround for this might be to change the regex to /^\s*#\s+/ to only recognize comments when there is at least one space between the # and the text after it. Obviously people could submit actual comments using that method as well (which we wouldn't like) but that would fix most cases where the issue is they didn't remove the initial comments after creating a blank spec.

What do you think?

[Linter] Grey areas

I'm sure everyone can pipe in, but with the number of linter improvements I've made I'd like to see if we can make a bit more of a concrete list of areas that we should be checking for inside of it. This will also help keep things a bit more organized/documented on what we need to work on in this area.

cc/ @irrationalfab, @alloy, @Keithbsmiley, @orta

Unify handling of redirects, etc. for validation of URLs

This should be a module in Core to avoid code duplication between Core and CocoaPods itself. It will support validating URLs despite of redirects and some common errors we identified so far.

As I touched that code a lot recently, I will do it myself.

[Linter] Resource bundles should prevent a pod from being considered empty

See CocoaPods/#1836

Empty Specs

A spec should not be considered empty if it has a framework in vendored_frameworks even if that is the only attribute where it includes source files. check_if_spec_is_empty should also check for vendored_frameworks in this array

[Linter] Check wether the name of the Pod starts with `.`

The check should be implemented here: https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/linter.rb#L209-L211.

[Specs] Fix coverage report

Improve fuzzy search for in the Pod::Source class

Support for fuzzy search has been already implemented in the Source class, although the cocoapods gem is not taking advantage of it yet. Currently the implementation is backed by the fuzzy_match gem which however appears to be geared to a slightly different use case that the one we are looking after.

One major limitation is that it doesn't take into account case to tokenize the names of the Pods. For example I consider convenient ObjSug to indicate ObjectiveSugar. This is very convenient for commands like pod spec cat and for printing a suggestion to the user including a similarly named Pod if one dependency in the Podfile could not be resolved.

Ruby 2.0.0 + cocoapods 0.21 issue (FileList)

Just updated ruby to 2.0.0 and cocoapods to 0.21

when I'm trying to lint:

 pod repo lint master 

i have :

-> The specification defined in `/Users/flop/.cocoapods/master/cocos2d/2.0/cocos2d.podspec` could not be loaded.

Invalid `cocos2d.podspec` file: uninitialized constant Pod::FileList
 #
 #  from /Users/flop/.cocoapods/master/cocos2d/2.0/cocos2d.podspec:14

And same issue in some other podspecs

It can be fixed just by adding

  require 'rake'
  FileList = Rake::FileList 

in podspec file

dsl.rb includes deprecated documentation attribute; causes incorrect documentation

lib/cocoapods-core/specification/dsl.rb lists the documentation attribute as an available option, but this attribute was deprecated in 0.20.0. Because dsl.rb is used to generate Cocoapods' documentation, this causes the Specification documentation to incorrectly list the documentation attribute as still being available.

OS X `vendored_frameworks` should automatically get embedded appropriately.

This means that the framework should:

• Automatically get copied into the app bundle in the Frameworks dir.
• Automatically configure the application to load frameworks from the Frameworks dir, if they use @rpath.

Currently you have to do the following:

  s.osx.vendored_framework = "PLCrashReporter-1.2-rc2/Mac OS X Framework/CrashReporter.framework"
  s.osx.resource = "PLCrashReporter-1.2-rc2/Mac OS X Framework/CrashReporter.framework"
  s.osx.xcconfig = { 'LD_RUNPATH_SEARCH_PATHS' => '@loader_path/../Frameworks' }

Somewhat related to #57.

[Linter] Refactor

• The code style checker is having a fit about the linter growing to be too big. We either need to refactor some of the logic into another class or modify the code styler to allow for more additions.
• Explore the inclusion of validation related properties in the DSL attributes directly #50 (comment)
• Convert the mixing to a dedicated class - #50 (comment)

• Allow Attribute Names to be Passed Into Results (#127)
• Linter results should keep attribute and message separate (#135)

edit by @fabiopelosin

[Linter] Disallow the use of the vendored_frameworks for iOS specs

originally reported by @alloy in #44

Disallow the use of the vendored_frameworks for iOS specs. These are not frameworks, but instead are static libraries disguised as frameworks and this makes it harder to use these specs outside of the context of Xcode. E.g. with clang from the command-line. Ideally this would also check the xcconfig attribute to ensure it’s not adding any FRAMEWORKS_SEARCH_PATHS.

[Specification] Refactor

The DSL should be isolated as much as possible from the Specification class which should be concerned only in handling the attributes hash and provide ancillary support. The specification should still be based on the attributes.

Moreover the specification consumer and its division of root attributes is counter intuitive and this should be fixed.

[Linter] check wether social_media_url is set to the example value

From CocoaPods/CocoaPods#1927

Pre-release Versions Do Not Conform to Semantic Versioning Spec

This is a migration of the issue tracked on CocoaPods/CocoaPods#583 and the associated Pull Request CocoaPods/CocoaPods#584 into the Core module.

I just pushed a version of the RestKit Podspec with the version 0.20-dev. On testing the installation, version.rb blew up at me complaining that the version string is malformed. I checked the Podspec format document @ https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format, which says that the version attribute reference should consult Semver.

Looking at the Semantic Version docs @ http://semver.org/ it says this about pre-release versions:

A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
The version enforcement should be updated to match the specification. Pull request forthcoming...

Find a way to access the contents of a Source without evaluating the specifications

[Specs] Remove blocks used to configure objects backed by the DSL

The objects should be configured using the API offered for programmatic access.

Example

[Specification] Strip indentation from all the spec attributes which might use a multiline string

This is already done for the license and for the description.

It should be done also for the:

• prefix_header
• prepare_command

The homepage is not reachable.

I think this error is providing some false positives. I'm getting this for the Baidu-Analytics-SDK where the homepage URL is: http://mtj.baidu.com/ which redirects to http://mtj.baidu.com/web/welcome/login

I'm not sure if this is just a redirection issue or if that's intentional since it doesn't return a 200.

Issues while using 0.17

I’m just gonna list issues here as I come across them.

A local dependency, specified with the :local option, that isn't expanded (e.g. contains a tilde) or can’t be found results in an exception

No such file or directory - ~/Code/Fingertips/github/FTWebViewController
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/generator/documentation.rb:63:in `chdir'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/generator/documentation.rb:63:in `generate'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:134:in `block in generate_docs'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:133:in `generate_docs'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:84:in `install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:312:in `install_source_of_pod'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:282:in `block (2 levels) in install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:281:in `block in install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:279:in `each'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:279:in `install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:91:in `block in install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:89:in `install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command/project.rb:40:in `run_install_with_update'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command/project.rb:70:in `run'
/Users/eloy/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/claide-0.2.0/lib/claide.rb:535:in `run'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command.rb:36:in `run'
/Users/eloy/code/CocoaPods/CocoaPods/bin/pod:16:in `<main>'

A normal install is too noisy

Finding Podfile changes:
Resolving dependencies of `Podfile`
Resolving dependencies for target `default' (iOS 6.0)
Comparing resolved specification to the sandbox manifest:
Downloading dependencies
Using CocoaLumberjack (1.6)
Using DirectoryWatchdog (1.0.0)
Using FTWebViewController (0.0.1)
Using HockeySDK (2.5.5)
Using SYPaginator (0.0.1)
Using StyledPageControl (1.0)
Generating Pods Project
Integrating client projects

At the very least, the first 4 lines could be condensed to something short like ‘Resolving dependencies’.

The deletions are also too verbose:

Removing deleted dependencies
Removing StyledPageControl

I’m leaning towards just showing the first line only, but I’m not sure yet.

Another option, which is more like how it currently works, is to make ‘Installing X’ lines green and ‘Deleting X’ lines red (in which case only the second line of the above example should be used).

Directories in resources patterns are not matched

Take for instance the SYPaginator lib, which specifies the following resources pattern: Resources/*. Previously this lead to the following lines in the resources script:

install_resource 'SYPaginator/Resources/de.lproj'
install_resource 'SYPaginator/Resources/en.lproj'
install_resource 'SYPaginator/Resources/es.lproj'
install_resource 'SYPaginator/Resources/fr.lproj'
install_resource 'SYPaginator/Resources/id.lproj'
install_resource 'SYPaginator/Resources/it.lproj'
install_resource 'SYPaginator/Resources/ja.lproj'
install_resource 'SYPaginator/Resources/ko.lproj'
install_resource 'SYPaginator/Resources/ms.lproj'
install_resource 'SYPaginator/Resources/nl.lproj'
install_resource 'SYPaginator/Resources/pt.lproj'
install_resource 'SYPaginator/Resources/pt_PT.lproj'
install_resource 'SYPaginator/Resources/ru.lproj'
install_resource 'SYPaginator/Resources/sv.lproj'
install_resource 'SYPaginator/Resources/SYPaginatorResources-Info.plist'
install_resource 'SYPaginator/Resources/zh_Hans.lproj'
install_resource 'SYPaginator/Resources/zh_Hant.lproj'

But currently only adds:

install_resource 'SYPaginator/Resources/SYPaginatorResources-Info.plist'

So it’s clear that all the directories are being ignored and it only includes files.

The xcworkspace document is regenerated when it isn’t necessary and removes unrelated xcodeproj references.

I have a workspace that was previously generated by CocoaPods 0.16. Later on I added a third unrelated Xcode project to the workspace. This has always been fine, because CP would change the workspace anymore.

Now it regenerates the workspace but does not include the third unrelated project.

Before:

<?xml version='1.0' encoding='UTF-8'?>
<Workspace version='1.0'>
  <FileRef location='group:Report 2012.xcodeproj'/>
  <FileRef location='group:Vendor/PSPDFKit-2.8.2/PSPDFKit/PSPDFKit-lib.xcodeproj'/>
  <FileRef location='group:Pods/Pods.xcodeproj'/>
</Workspace>

After:

<?xml version='1.0' encoding='UTF-8'?>
<Workspace version='1.0'>
  <FileRef location='group:Report 2012.xcodeproj'/>
  <FileRef location='group:Pods/Pods.xcodeproj'/>
</Workspace>

DSL directive to exclude subspecs in the Podfile

I shouldn't have to write the following (well, regex it from the lockfile) in order to exclude a single subspec which has a broken dependency:

pod 'libextobjc/EXTADT'
pod 'libextobjc/EXTAnnotation'
pod 'libextobjc/EXTBlockMethod'
pod 'libextobjc/EXTBlockTarget'
pod 'libextobjc/EXTConcreteProtocol'
pod 'libextobjc/EXTDispatchObject'
pod 'libextobjc/EXTFinalMethod'
pod 'libextobjc/EXTKeyPathCoding'
pod 'libextobjc/EXTMaybe'
pod 'libextobjc/EXTMixin'
pod 'libextobjc/EXTMultimethod'
pod 'libextobjc/EXTMultiObject'
pod 'libextobjc/EXTNil'
pod 'libextobjc/EXTPassthrough'
pod 'libextobjc/EXTPrivateMethod'
pod 'libextobjc/EXTProtocolCategory'
pod 'libextobjc/EXTSafeCategory'
pod 'libextobjc/EXTScope'
pod 'libextobjc/EXTSelectorChecking'
pod 'libextobjc/EXTSwizzle'

Add a check for merge conflict markers in YAML files

You get a non-trivial to figure error report:

Psych::SyntaxError - (<unknown>): could not find expected ':' while scanning a simple key at line 14 column 1
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:205:in `parse'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:205:in `parse_stream'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:153:in `parse'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:129:in `load'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-core-0.29.0/lib/cocoapods-core/lockfile.rb:43:in `from_file'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/config.rb:208:in `lockfile'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command/project.rb:36:in `run_install_with_update'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command/project.rb:68:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/claide-0.4.0/lib/claide/command.rb:213:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command.rb:51:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/bin/pod:24:in `<top (required)>'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/pod:23:in `load'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/pod:23:in `<main>'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `eval'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `<main>'

From:

PODS:
  - Kiwi (2.2)
  - ObjectiveSugar (1.1.1)

DEPENDENCIES:
  - Kiwi
  - ObjectiveSugar (from `../`)

EXTERNAL SOURCES:
  ObjectiveSugar:
    :path: ../

SPEC CHECKSUMS:
<<<<<<< HEAD
  Kiwi: 05f988748c5136c6daed8dab3563eca929399a72
  ObjectiveSugar: 7377622e35ec89ce893b05dd0af4bede211b01a4
=======
  Kiwi: db174bba4ee8068b15d7122f1b22fb64b7c1d378
  ObjectiveSugar: 27c680bb74f0b0415e9e743d5d61d77bc3292d3f
>>>>>>> b65623cbf5e105acbc3e2dec48f8024fa82003ce

COCOAPODS: 0.29.0

Where an error message would be super useful for a lot of people.

This is opened as a duplicate of CocoaPods/CocoaPods#1847 as the issue would be better fixed here in core.
//cc @orta

Gist https validation error

Seems like there is an error when linting a spec that points to gist.github.com. Even when the spec points to the https link the validation fails. Lint output https://travis-ci.org/CocoaPods/Specs/builds/13016103#L169 for spec https://github.com/timshadel/Specs/blob/d9d26c59d80cf63ac121419371f32380b1c6a8ce/UIImageEffects/0.0.1/UIImageEffects.podspec

CocoaPods/Specs#3509
CocoaPods/Specs#4946

[Linter] Improve libraries, vendored_libraries, vendored_frameworks check

Ensure the libraries and vendored_libraries attribute contains e.g. ‘foo’ and not ‘libFoo.a’.
Ensure the vendored_frameworks attribute contains e.g. ‘Foo’ and not ‘Foo.framework’.

Pod not building with dependancy's framework

I've created a pod that depends on the Parse pod. My podspec includes the line

s.dependency "Parse"

When I create a new project and try to use my pod (https://raw.github.com/pyro2927/ParseQuickDialog/master/ParseQuickDialog.podspec) and build, I get an error that Pods-ParseQuickDialog has an issue where Parse/Parse.h cannot be found. I'm guessing this is due to the fact that the Parse iOS SDK is distributed via a framework and not source code, but I'm unsure as to how to fix the problem.

My guess is the Parse framework isn't being included in the build process for my pod (ParseQuickDialog), but I don't know where that needs to be fixed.

spec.author !== spec.authors

Pod::DSLError - Invalid `ARAnalytics.podspec` file: undefined method `author=' for #<Pod::Specification name="ARAnalytics">

I had to make this commit: orta/ARAnalytics@5a935dc in order to not have cocoapod 0.17 rc5 give install issues

Resolve redirections

Often when users rename there github accounts there is a linter failure when they add a new spec. It fails saying something like:

- ERROR | The source of the spec doesn't match with the recorded ones. Source: `https://github.com/supermarin/ObjectiveRecord.git`. Previous: `https://github.com/mneorr/Objective-Record.git`
Please contact the specs repo maintainers if thelibrary changed location.
-> The spec cannot be accepted.

from

It would be great if the linter could follow the redirections to see that the URL is actually the same in both cases.

Pod version resolution issue when both Podfile and pod depend on different versions of same dependency

I've found a very subtle yet potentially serious issue where the version of a dependency is miscalculated or multiple copies of the dependency are installed.

Note that I assume this is an issue in Core based on my guess of how the various CocoaPods repos depend on each other. Let me know if this issue is mis-filed and I will happily recreate in the correct repo.

---

This issue originally arose when my app's Podfile depended on a loose (~> 2.0) version of an AFNetworking subspec. Two pods called out in the Podfile also depended on loose versions of AFNetworking subspecs. When I ran pod install on 2/26 (when 2.2 was released), I ended up with both 2.1.0 and 2.2.0 versions of AFNetworking installed on top of each other, causing compiler issues.

I've since determined that whether the Podfile specifies a dependency on the subspec or the top-level spec does not matter. The version of the dependency in the Podfile also doesn't matter much since even pinning it to a specific version (= 2.1.0) causes the issues. What matters is the (shared) dependency declaration in the referenced podspec.

Issue Cases

1. Two different versions of a shared dependency installed
2. The latest version of a shared dependency installed, despite the Podfile forbidding it with version pinning

Conditions

• Pod which depends on the shared dependency must appear before it in the Podfile
• Pod which depends on the shared dependency must have a name string sorted after it (install progress shows in this order)
• .podspec
  • If pod depends on a subspec of the shared dependency, both the Podspec-pinned version and the latest version of it will be installed (Issue case 1 above).
  • If pod depends on the top-level spec of the shared dependency, only the latest version of it will be installed (Issue case 2 above).

shared dependency == AFNetworking

---

I've created a project which reproduces these issues at https://github.com/phatblat/SubspecUpdateIssue. Toggle the AFNetworking dependency lines in ZPodUsingAFN.podspec between the subspec and the top-level spec and run pod install to witness the above 2 issue cases.

If someone gives me some pointers on the pertinent details I might be able to include them in an example at https://github.com/CocoaPods/cocoapods-integration-specs/.

---

Reproducing the case where pod install upgrades a pod it shouldn't have with a fuzzy version spec (~> 2.0) is harder to reproduce as it requires a Podfile.lock created while the offending version didn't exist. However, I believe the above cases are enough to resolve the current issue since it's reproducible with a pinned version in the Podfile.

Pre-release versions should not be matched when using the < version operator

This issue was first found at the CocoaPods level and reported in issue CocoaPods/CocoaPods#1489

Relevant discussion from that issue:
@jominius:

Original Title: CocoaPods versioning “< 2.0” tried to install “2.0.0-RC3”
I have a project, which was using some unknown old version of AFNetworking. I converted the project to CocoaPods and wrote "pod 'AFNetworking', '< 2.0'" into pod file.
Found out that "pod install" tried to install AFNetworking version 2.0.0-RC3. Fortunately it wasn't compatible with the project and I got a warning about it.

@alloy:

Yes, we should not install rereleases unless explicitly requested by the user. E.g. pod 'AFNetworking', '2.0.0-RC3'.

@luisdelarosa:

I submitted a pull request with several tests, one of which is failing and reproduces the issue that @jomnius reported.
After further investigation, this looks like it will have to be fixed in Core, probably in dependency. I think it would still be good to have these tests at the CocoaPods level, though.

[Specification] Use string for all the keys

Currently the sub keys of the hashes use symbols (e.g. source the source params like :git). There is already logic there to handle the conversion when appropriate... but all the keys should be used as strings and converted, if needed, by the consumer.

This would also lead to a cleaner Lockfile:

EXTERNAL SOURCES:
  IFBKCampground:
    :git: https://github.com/irrationalfab/IFBKCampground.git
  IFBKThirtySeven:
    :path: ../../IFBKThirtySeven
  IRFAutoCompletionKit:
    :git: https://github.com/irrationalfab/IRFAutoCompletionKit
  IRFNavigationKit:
    :git: https://github.com/irrationalfab/IRFNavigationKit.git)

Related: CocoaPods/CocoaPods#1058 (comment)

@alloy we need to double check this for trunk because the JSON podspec return strings.

Should SSH access be checked in the master repo?

We had an issue pop up in the specs repo CocoaPods/Specs#10877 where a contributor submitted a spec using git@github...

However, specs should be using https. I notice the local linter passes this fine, which I can understand for private repos, but I wonder if this behaviour should not pass if contributing to the master repo?

There's quite a discussion in that pull request so I thought it might be more appropriate to raise an issue here instead.

Framework validation issue

Frameworks should be allowed to have more than just letters and numbers. As it currently stands those are the only characters allowed although some frameworks have - in the name. This can be fixed by changing the regex to /[^a-zA-Z\-\d]/ and writing a test or two.

[Source] Gracefully handle unexpected source structure

A proper informative message should be provided in the following cases:

• There is an unrecognised directory which should represent a version.
  • Related: CocoaPods/CocoaPods#2038
• The podspec could not be found (maybe this is already handled)

A good starting point is the Pod::Source::FileSystemDataProvider#versions method.

Resources script fails if UNLOCALIZED_RESOURCES_FOLDER_PATH contains spaces

With the latest version of CocoaPods, the resources script is failing. I believe I've tracked it down to b32cae7888e1feb9432da177b65193ce8547331f, which removed the quotes around the second part of the xcrun command.

Was this a mistake, or were they removed for a reason?

Validation in the HTTP module could mask errors

Currently, we just catch all exceptions there

Core/lib/cocoapods-core/http.rb

Line 44 in b20ca02

rescue

We should evaluate which specific error conditions we want to ignore. Invalid URIs should be checked before even making the request and get their own specific error messages.

Use git API in GitHubDataProvider to get versions along the list in a single call

https://api.github.com/repos/CocoaPods/Specs/git/trees/HEAD?recursive=1

Find a way to warn users about the changes to the specification hooks

from

Pod::Spec.new do |spec|
  def spec.pre_install(pod, target_definition)
    Dir.chdir(pod.root){ `sh make.sh` }
  end
end

to

Pod::Spec.new do |spec|
  spec.pre_install do |pod, target_definition|
    Dir.chdir(pod.root){ `sh make.sh` }
  end
end

/cc @alloy

Add a spec variable for giving post install messages

This could be useful if a pod isn't as simple as install and #import

[Linter] The public_header_files attribute should allow only headers

Originally reported in #44 (comment)