got an error; don't know what the problem was about p5-dist-zilla-plugin-github

[ghedo]

AFAICT the "Not Found" comes from GitHub, and if it were a permission issue it would have said so. More likely it's that the plugin guesses the wrong repository URL. Right now it tries to extract user+repo from one of the repository remotes (origin by default) if it fails that it uses the user's login credential and the dist name.

Could you please run git remote -v on your local repository? My guess is that there's no origin remote and the plugin tries to update karenetheridge/Dist-Zilla-Plugin-Test-CheckDeps which doesn't exists. The solution here would be to add a remote = ... to the plugin config (or change the remote name to origin).

Otherwise it would help if you could put a die $repo; in lib/Dist/Zilla/Plugin/GitHub.pm just before the return in the _get_repo_name sub, so that we know what it's trying to do.

[ghedo]

The solution here would be to add a remote = ... to the plugin config (or change the remote name to origin)

...or explicitly configure the repository name with repo = Leont/dist-zilla-plugin-test-checkdeps

[karenetheridge]

: [ether@tequila git/Dist-Zilla-Plugin-Test-CheckDeps].8$; git remote -v
origin  [email protected]:Leont/dist-zilla-plugin-test-checkdeps.git (fetch)
origin  [email protected]:Leont/dist-zilla-plugin-test-checkdeps.git (push)

I created an inc::gh that contained the code from Dist::Zilla::Plugin::GitHub::Update, with s/AfterRelease/AfterBuild/ and s/after_release/after_build/g, then did a 'dzil build'... the repo name coming back from _get_repo_name is correct, ''Leont/dist-zilla-plugin-test-checkdeps'.

I also dumped the parameters being sent, and the $json_text received:

### sending params: $VAR1 = {
          'description' => 'Check for presence of dependencies',
          'homepage' => 'http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-CheckDeps/',
          'name' => 'dist-zilla-plugin-test-checkdeps'
        };
### got response: $VAR1 = {
          'message' => 'Not Found',
          'documentation_url' => 'http://developer.github.com/v3'
        };
[=inc::gh] Err:  Not Found

[ghedo]

Ok, I got this... apparently I was wrong and GitHub returns a 404 when you don't have edit permission. So yeah, it is a permissions issue. Not sure what'd be the best way to handle this on GitHub::Update's side though. Maybe print "Not found (or permission denied?)" when 404 is received, but that's not very helpful either.

[karenetheridge]

yeah, if 404 is all we get, then the best you can do is guess why the error might have occurred...

[karenetheridge]

I'm disappointed with github here - they should be returning a different error than plain old 404 in this case.

[karenetheridge]

Ran into this again, and saw:

[@Author::ETHER/GitHub::Update] Updating GitHub repository info
[@Author::ETHER/GitHub::Update] Using MetaCPAN URL
[@Author::ETHER/GitHub::Update] Err:  Not Found
Use of uninitialized value $repo in string eq at /Users/ether/.perlbrew/libs/21.1@std/lib/perl5/Dist/Zilla/Plugin/GitHub/Update.pm line 145.

The repo in question was [email protected]:Getty/p5-dist-zilla-plugin-run.git, which suggests it's another permissions problem. Line 145 should be aware that $repo might be undefined.

[ghedo]

[@author::ETHER/GitHub::Update] Err: Not Found

I'm still not sure on what would be the best way to handle this. The error message I proposed above seems quite confusing for the user, but at the same time I don't have any other ideas.

Use of uninitialized value $repo in string eq at ...

Eh, a new bug I guess...

[ghedo]

The "Use of uninitialized value" warning should be gone now.

[karenetheridge]

On Thu, Jul 24, 2014 at 12:13:37PM -0700, Alessandro Ghedini wrote:

The "Use of uninitialized value" warning should be gone now.

Awesome, thanks!

[autarch]

I'm getting this too, but hte problem seems to be that HTTP::Tiny is returning a hash, not a JSON blob of text.

I note that the _check_response method in Plugin ignore the value of the exception in the catch sub. It might be useful to output that.

But I'm trying to figure out why HTTP::Tiny is returning what appears to be the already-decoded JSON structure.

[autarch]

Oh, I see, HTTP::Tiny returns a hash, but content is undecoded. I'll investigate further, apparently the JSON module is unhappy with the JSON GitHub is returning here.

[karenetheridge]

Oh yes, I meant to come back to this ticket and note that I still get the "Err: Not Found" response when releasing to any repository that doesn't belong to my own user account -- e.g. something in the moose org, or a repo belonging to another user -- so I wonder if the wrong API is being used?

[autarch]

@karenetheridge - I think all queries were broken by your last patch - see #45

This distro could really use some tests, although I'm sure writing them would be a bit of a pain with the mocking it'd require.

[karenetheridge]

It does seem to work some of the time - the last time I minted a new dist, on the first release I did see the repo metadata get updated with the ABSTRACT. But I'll take a look - it should be possible to write some tests for this - I think this is the first time I've had a need for an HTTP::Tiny equivalent to Test::LWP::UserAgent :)

[ghedo]

@autarch @karenetheridge So, here's the thing. I haven't done any real Perl development in a while and probably won't any time soon (not sure if it's just a phase...). I've tried to keep up with pull requests and such but I'm not really much interested anymore and it seems I'm not doing a very good job (e.g. I didn't properly test #44, which caused #45), so if any of you is interest in adopting this module and continuing development that would be nice (FWIW, except for FFI::Raw, my other Perl stuff is up for grabs too), otherwise it's gonna take me some time to look into any issue.

[autarch]

@ghedo - If you give @karenetheridge and I maint on the module I'm sure we can figure something out.

[karenetheridge]

Yep, I'm looking at this tonight -- since I broke it, I should fix it :)

On Wed, Jan 7, 2015 at 1:50 PM, Dave Rolsky [email protected]
wrote:

@ghedo https://github.com/ghedo - If you give @karenetheridge
https://github.com/karenetheridge and I maint on the module I'm sure we
can figure something out.

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

[karenetheridge]

Yep, I'm looking at this tonight -- since I broke it, I should fix it :)

Naturally I wrote that just before seeing PR #45 :)

[ghedo]

Ok, so I made both @autarch and @karenetheridge collaborators to this repo, and co-maintainers on CPAN (I hope I got the PAUSE user names right).

I'm also willing to give up primary maintainership and transfer this repo to someone else if you pick someone of you, as long as I'm kept as collaborator here on github and cpan (it's really just pro forma... I'd like to keep track of things).

[karenetheridge]

awesome, thanks! I merged #45 and released as v0.40, which should get us unstuck. I'd be happy to take on a more serious adoption of this module, but I thought it was more important to get the fix out first.

I'm closing this ticket as it's now drifted way off of its original intent. :)
thanks again!

[karenetheridge]

oops, looks like I'm still missing comaint on:
Dist::Zilla::App::Command::gh
Dist::Zilla::PluginBundle::GitHub

(see the results at Dist::Zilla::PluginBundle::GitHub)

[ghedo]

Dammit, I knew I missed something. Should be fixed now.