use ogr instead of our custom github api client
Closed this issue · 13 comments
We have developed a pretty solid library which makes it easy to connect to various git forges, it's available over here:
https://github.com/packit-service/ogr
We should get rid of present github-related code we have now and replace it with ogr. It may be possible that we have to add functionality into ogr.
This would also make it trivial to support pagure.io CC @pypingou
I am working on it!
I think this would at least require https://github.com/packit-service/ogr/blob/master/ogr/abstract.py to be implemented (instead of porting it now and then porting it again to abstract), that would provide a better replacement for the git and github classes (and make it easy to implement all the extra utility functions like 'walk_through_open_issues' etc.)
@Toaster192 we already have pagure support in ogr: https://github.com/packit-service/ogr/blob/master/ogr/services/pagure.py
@TomasTomecek Yeah but wouldn't it make more sense to finish the abstract interface for ogr so it works regardless (github / gitlab/ pagure) and then use that for release-bot?
I feel like there would be a lot of redundant code later
Yeah but wouldn't it make more sense to finish the abstract interface for ogr so it works regardless (github / gitlab/ pagure) and then use that for release-bot?
I am not sure if I got your point, but If you miss something in the ogr API, feel free to send PR there. (So we have the code only there and avoid the redundant code.)
(And also we can benefit in other projects that use ogr.)
@lachmanfrantisek Correct me if I'm wrong but the abstract.py is a sort of a interface so you can use the ogr API without having to keep all the different repo-hosting platforms in mind? And there seems to be functions not yet implemented that would be useful for release-bot, for example the 'get_pr_list()' for the 'walk_through_prs()' in release-bot/github.py. Without those functions implemented in ogr they would need to be implemented in release-bot and thus, if they got implemented later in ogr, would be redundant.
Don't you think making the API better(/more useful to the project) before using it would work better (and, as you said, benefit other projects)?
(I'm sorry if what I'm saying doesn't make sense or if I'm repeating myself too much, thank you for your feedback)
the abstract.py is a sort of a interface so you can use the ogr API without having to keep all the different repo-hosting platforms in mind?
Yes
And there seems to be functions not yet implemented that would be useful for release-bot, for example the 'get_pr_list()' for the 'walk_through_prs()' in release-bot/github.py.
You mean the raise NotImplementedError() in AbstractProject?
It is just a default implementation. The particular services should override this - like get_pr_list in GithubProject.
Don't you think making the API better(/more useful to the project) before using it would work better (and, as you said, benefit other projects)?
We can use and update the ogr on the fly. (Since the ogr is ours, we can update/release it quickly.)
Oh, I missed that it was getting overriden
I'll make sure to put more work into it before I annoy message you guys again, thanks a lot!
Oh, I missed that it was getting overriden
I'll make sure to put more work into it before I annoy message you guys again, thanks a lot!
No problem.;-)
I looked at this issue closer and I'm a little bit skeptical. Firstly, I thought that this will need just some changes inside bodies of functions from rest API/graphQL API with ogr. But now I think this could be quite a complex problem which means change function's declarations, write or delete more functions maybe classes. Write or delete tests and so on.
However, I didn't give up I created an issue in ogr repo with some questions. I will see if we can make it easier.
But now I think this could be quite a complex problem which means change function's declarations, write or delete more functions maybe classes. Write or delete tests and so on.
I hope there will be more deletions. If there is anything missing from the perspective of GithubAPI, it is better to add it to the ogr, so multiple projects can benefit from it...
Yup, this is definitely not a trivial issue to solve.