briandfoy / ghojo Goto Github PK

That's in lib/Ghojo.pm and should be an easy fix

single_resource and get_paged_resource need to be able to handle this somehow. There are several other design issues related to this, so talk to me first if you'd like to work on this.

That could be a plain string that is a filename, or a scalar reference which is the config.

In render_markdown in Miscellaneous.pm, you can pass a repo argument. Check that the repo exists before I even validate the profile (or make it part of the profile validation). See #32.

But it's also in a response header. Do something to let the user check that or to not make a request when the rate is over limit.

I don't think the response header is enough. It knows how many have been made in the last hour, but it doesn't know how many will not be part of that count a minute later.

The rate limits are documented at: https://developer.github.com/v3/#rate-limiting

The License part of the API only tracks the top 10 or 12 licenses in GitHub (and artistic is not one of them). When we get the license data and the name is "Other", recognize it and fix it up.

This one is easy. You need some easy stuff for Hacktoberfest to get that t-shirt!

This depends on #23, #24, and #25.

Once I do that, I can change my GitHub creator module.

This is in lib/Ghojo/Endpoint/Miscellaneous.pm. The get_rate_limit returns a result that includes a Ghojo::Data::RateLimit object, but we don't call methods on that object. We go through the Ghojo::PublicUser object which interacts with the cache.

Can't use an undefined value as an ARRAY reference at Ghojo.pm line 1351.

I think this might comes from a request that sends back something that isn't the expected JSON. Perhaps rate limiting?

I like the sidebar on rt.cpan.org that shows the open / stalled / patched tickets for each of my modules. I want the same thing for GitHub.

Provide some subroutines to validate types like iso8601, repo exist, and so on. This would be nice for #31.

I want a ::Response::Repository object, for instance. It doesn't have to be fancy. Use Hash::AsObject, for instance. However, it's more than just the data structure. If there's an error, the returned object should return info about that. My ReturnValue module might be interesting here.

The part of the API that creates a repo can choose a gitignore template from https://github.com/github/gitignore. I want to get a list of those templates to validate input. That is, when Ghojo runs, it should get the current state of that list.

https://developer.github.com/v3/repos/#create

It's in the transactor object, like this:

$ua->transactor->name('MyUA 1.0');

The Label JSON has only the name, color, and URL. From that, we should be able to call update or delete on the Ghojo::Data::Label object and translate it into the right endpoint stuff. The programmer shouldn't know about any of this.

Additionally, we should be able to do this with any sorta thing that can update or delete or be attached to something. Labels, comments, reactions, whatever.

Can't locate object method "logger" via package "Ghojo::Result" at /Users/brian/Dropbox/Dev/Ghojo/examples/common_things.pl line 51.
make: *** [all] Error 22

If we try to log in with a username and password and we can't, tell the user somehow and don't return an object.

At the moment, as soon as we login I create a new authorization (so, a new Personal Access Token). Maybe people don't always want that. Provide a way for them to login without in.

I think I'm in favor of different constructors instead of one constructors with lots of inputs. The current one can be DWIM, but other restrictive ones can do only exactly what they are told to do.

And, let the user decide what to name it! This would be a change to create_authorization at the line like

    $hash->{note}   //= 'test purpose ' . time;

Some endpoints return virtually static responses (such as the list of licenses). Create a way to cache those (and a way that someone can avoid the cache). A cache might be for the lifetime of the program or might expire. Most of this should be hidden. Results from the cache should be marked as such.

The part of the API that creates a repo can choose a license from https://github.com/github/choosealicense.com/tree/gh-pages/_licenses . I want to get a list of those licenses to validate input. That is, when Ghojo runs, it should get the current state of that list.

https://developer.github.com/v3/repos/#create

But don't go crazy with dependencies doing it

See the design goals I put in the Ghojo module. I haven't made CONTRIBUTING docs before because I'm not terribly picky, so almost anything you put in a PR I'll accept!

The README includes this:

You can read the documentation and inspect the meta data on one of the CPAN web interfaces, such as CPAN Search or MetaCPAN:

    http://search.cpan.org/dist/Ghojo
    http://www.metacpan.org/module/Ghojo

The standard module documentation has example uses in the SYNOPSIS section, but you can also look in the examples/ directory (if it's there), or look at the test files in t/.
Installation

You can install this module with a CPAN client, which will resolve and install the dependencies:

        % cpan Ghojo
        % cpanm Ghojo

However, both of those links give 404s, so the library is not yet installable from CPAN.

This was noted in the course of a discussion on the Madrid Perlmongers mailing list.

Do you expect to put this on CPAN soon?

Not all of the responses are Arrays of Hashes.

We shouldn't log that stuff!

If we get a token from create_authorization in, we delete the password. We can't delete the token though. We don't want it to leak out in a log message.