Skip to content


Spec create crash with private remotes #1543

mattyohe opened this Issue · 12 comments

6 participants



  • What did you do? Ran spec create:
pod spec create
  • What did you expect to happen?
    I assume a spec would be created with (as the Usage claims) pre-populated fields.

  • What happened instead?
    The crash below occurred.


   CocoaPods : 0.27.1
        Ruby : ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin12.2.0]
    RubyGems : 1.8.24
        Host : Mac OS X 10.9 (13A603)
       Xcode : 5.0.1 (5A2053)
Ruby lib dir : /Users/mattyohe/.rvm/rubies/ruby-1.9.3-p194/lib
Repositories : CocoaPods-InternalSpecs - @ 57f05c6853cf92cea92837cd9f7a234c584a21ce
               master - @ 5c6e7f1565e56672df272e18a4ba2446e88d9ac8


NoMethodError - undefined method `[]' for nil:NilClass
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/cocoapods-0.27.1/lib/cocoapods/command/spec.rb:402:in `github_data_for_template'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/cocoapods-0.27.1/lib/cocoapods/command/spec.rb:36:in `run'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/claide-0.3.2/lib/claide/command.rb:206:in `run'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/cocoapods-0.27.1/lib/cocoapods/command.rb:51:in `run'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/cocoapods-0.27.1/bin/pod:19:in `<top (required)>'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/bin/pod:19:in `load'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/bin/pod:19:in `<main>'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `eval'
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14:in `<main>'

However creating the spec with just a name seems to operate as expected.

CocoaPods member

Is the github repo public?


@orta Unfortunately no.

Curious though maybe I'm just mistaken and this is more of a Usage/Documentation bug...

My assumption here was that filling in the URL would simply pass that along to the spec's source method. Is this incorrect?

CocoaPods member

It will go and pull in a bunch of metadata from the github repo itself like name, description, author etc. So it could be we're making presumptions about what we can find on the repo.

CocoaPods member

This definitely is related to the repo being private. I guess we could take auth parameters, assuming the required code that’s needed is simple enough.

@mattyohe Interested in working on this?


@orta So right, I was just targeting at a bare repo at the moment. Again, only assuming it would grab like the title of the repo and use the URL in the source path.

Methinks this is more of an issue with my expectations of what this would actually do.


@alloy I need to work on my rubby skills before I'd feel comfortable helping out :D

CocoaPods member

Fair enough :)

To others, the calls are being made here with Nap and should use the following credentials.

CocoaPods member

The use of credential from netrc is tracked by #876


Issue has been confirmed by @neonichu

@CocoaPodsBot CocoaPodsBot was unassigned by mattyohe
CocoaPods member

Is this issue still relevant?


@fabiopelosin Well, I can confirm the issue is still present, but "relevant" is your call :smile:

@fabiopelosin fabiopelosin added a commit that referenced this issue
@fabiopelosin fabiopelosin [Command::Spec] Fix crash
Closes #1543
CocoaPods member

I think that fixing the crash is enough in this case. PR in #2479

@fabiopelosin fabiopelosin added a commit that referenced this issue
@fabiopelosin fabiopelosin [Command::Spec] Fix crash
Closes #1543
@segiddins segiddins closed this in #2479
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.