better error reporting please?

[wchristian]

This request ends up being broken, which might be ok, or not. I don't know because the error just tells me the request failed.

my $result = MetaCPAN::API->new->post(
    '/release/_search',
    {
        "query" => {
            "match_all" => {},
            "range"     => { "release.date" => { "from" => "2011-12-20T00:00:00", "to" => "2011-12-22T00:00:00" } },
            "size"      => 100,
        },
        "fields" => [ "release.name", "release.date" ]
    }
);

Maybe make it a bit more detailed please? :)

[xsawyerx]

How do you mean "being broken"?

I ran the test and got a result. Could you provide me more details about what you mean?

[wchristian]

Your addition here:

my $query_json = to_json( $query, { canonical => 1 } );

Prevented that error from occurring. Try removing the canonical and you should get an error from metacpan because elastic search barfs on unordered json.

[xsawyerx]

So this error was fixed by your pull request.

Can I close the issue then?

[wchristian]

That pull request fixed one error source. Possibly. Due to the error lying within ES i'm not even sure if just proper ordering makes it work in all situations. So the issue is that IF metacpan has any error, the output from MetaCPAN::API is useless, since it just goes "an error happened" instead of telling the user the error reported by metacpan itself.

[xsawyerx]

Ah, I see your point.

[kentfredric]

I've a good mind to patch in some support for alternative http backends via a sort of "adapter" model, at present you can pull a few tricks and use WWW::Mechanize as your HTTP engine instead of HTTP::Tiny using HTTP::Tiny::Mech , which allows you do to anything you can with WWW::Mech, but I'd like to make it "first-class" support for MetaCPAN::API so that users don't have to glue so many bolts together to use some features that I figure might be commonly wanting.

Presently I have a few additional tricks due to this, and it takes a bit of code to make work, but I have working:

• Request/Result Caching support via CHI
• Request Debugging support via dumping raw request/results.

my $mcpan;

sub mcpan {
  $mcpan ||= do {
    require CHI;
    my $cache = CHI->new(
      driver => 'File',
      root_dir => File::Spec->catdir( File::Spec->tmpdir, 'gentoo-metacpan-cache' ),
      expires_in => '6 hour',
      expires_variance => 0.2,
    );
    require WWW::Mechanize::Cached;
    my $mech;

    if ( defined $ENV{WWW_MECH_NOCACHE} ) {
      $mech = LWP::UserAgent->new();
    }
    else {
      $mech = WWW::Mechanize::Cached->new(
        cache => $cache,
        timeout => 20000,
        autocheck => 1,
      );
    }
    if ( defined $ENV{WWW_MECH_DEBUG} ) {
      require Data::Dump;
      $mech->add_handler(
        "request_send",
        sub {
          if ( $ENV{WWW_MECH_DEBUG} > 1 ) {
            warn shift->as_string;
          }
          else {
            warn shift->dump;
          }
          return;
        }
      );
      $mech->add_handler(
        "response_done",
        sub {
          if ( $ENV{WWW_MECH_DEBUG} > 1 ) {
            warn shift->content;
          }
          else {
            warn shift->dump;
          }
          return;
        }
      );
    }
    require HTTP::Tiny::Mech;
    my $tinymech = HTTP::Tiny::Mech->new( mechua => $mech );
    require MetaCPAN::API;

    MetaCPAN::API->new( ua => $tinymech );
    }
}

As you can see, thats a nasty bogload of code to expect the average metacpan::api consumer to use, and it would be better to have a more native way of supporting this.

[kentfredric]

@wchristian may want to check-out/stalk issue #10 I just opened to track some hacking on MetaCPAN::API =)

[xsawyerx]

@kentfredric I've only now seen this comment! I have no idea how I missed it for so long.

Your code seems kind of... hmm... tricky? Scary? I'm not exactly sure how to describe it. I'll take a more in-depth look at it tomorrow (now 2:30am) and check. I'll also reply to the other opening ticket.