pod spec create https://github.com/XXXXX/XXXXXX
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 - firstname.lastname@example.org:XXXXXXXX/CocoaPods-InternalSpecs.git @ 57f05c6853cf92cea92837cd9f7a234c584a21ce
master - https://github.com/CocoaPods/Specs.git @ 5c6e7f1565e56672df272e18a4ba2446e88d9ac8
NoMethodError - undefined method `' for nil:NilClass
/Users/mattyohe/.rvm/gems/ruby-1.9.3-p194/gems/cocoapods-0.27.1/bin/pod:19:in `<top (required)>'
However creating the spec with just a name seems to operate as expected.
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?
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.
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
Fair enough :)
To others, the calls are being made here with Nap and should use the following credentials.
The use of credential from netrc is tracked by #876
Issue has been confirmed by @neonichu
Is this issue still relevant?
@fabiopelosin Well, I can confirm the issue is still present, but "relevant" is your call
[Command::Spec] Fix crash
I think that fixing the crash is enough in this case. PR in #2479