Switching to API v3. - Githubissues

JNRowe / hubugs

Simple client for GitHub issues

https://hubugs.readthedocs.io/

GNU General Public License v3.0

6 stars 2 forks source link

Switching to API v3. #22

Closed JNRowe closed 12 years ago

JNRowe commented 12 years ago

One way or another API v3 is upon us. I'm finally fed up with not having access to the new features only available with v3 or a visit to the site, so it is time to switch.

The only question is "how?" I'm setting a self-deadline for the end of the month for making a decision on which new library(or custom wrapper) to use.

This issue is just a place to figure out the possibilities.

30 minutes with remoteobjects, or a final nudge to Matt to release his bindings under a usable licence.
One of the semi-working libraries registered on PyPI if they're ready for the job by the end of the month(and don't bring unusable deps in).
The choice that doesn't want to be made.

JNRowe commented 12 years ago

[Note to self here, but it is CC'd in part to the internal devtools list too]

a final nudge to Matt to release his bindings under a usable licence.

Matt isn't able to release his bindings, unfortunate but fair enough.

One of the semi-working libraries registered on PyPI if they're ready for the job by the end of the month

None of the packages on PyPI currently support enough of the API to handle even the functionality we have now, and they don't look like they'll be usable at any point in the near future :/

If you're inside the EADS firewall you can fetch the practical_matter branch, and see the sort of functionality we get from switching to Matt's library. This could well be the supported method going forward.

JNRowe commented 12 years ago

I'm just back from a two week break, and I haven't fully digested the API v3 migration post yet.

The problem is this issue needs resolving in the next few weeks or hubugs stops working, but I'm not sure I'll find the time to work on it. Quite frankly, it isn't a priority for me. We have a API v3 capable branch locally, but the dependencies aren't available for public consumption.

sorin-ionescu commented 12 years ago

There are no other tools. hubugs is the only good one.

JNRowe commented 12 years ago

There is an initial API v3 compatible version of hubugs in the feat/api_v3 branch. It works for me, but needs a lot of work still.

micromodels and requests are now required, but this may change before the next release is cut.
There is currently no support for caching, but it will be implemented before the next release.
It is very ugly, but I just decided to slam it down tonight and push it out there. Expect things to change.

Warning: I'm publishing this now, but don't expect it to be merged as-is to master. That said, feel free to open pull issues/requests against it.

JNRowe commented 12 years ago

Closed by 3cd9a9f6dff10325ce3b6f7bf1997c7d0c933a8f.

There is still a heap of work to do, but this is in a reasonable state now. There is a bunch of refactoring that needs to happen, and some of the functionality begs for polish.

Hopefully, I can start to merge the diverging codebases between EADS and GitHub. At that point I'll pick up development again.

There is currently no support for caching, but it will be implemented before the next release.

This isn't likely to happen before the next release now, as the granularity of the hooks support in requests is making this really quite annoying.