+1.

We should have at least three abstractions: Instance, Project and User.

Or shall we go deeper with dedicated classes for issues and pull-requests?

I think Pagure API is not too complex. Hence, starting with 3 abstractions mentioned by you would be a good idea. Remaining could be left for future enhancement if required.

Just started working on it. I'm now going with 2 abstractions, Instance and Project.

Sounds good! Looking forward to enhancements. I might be able to integrate libpagure to my project - https://github.com/nirzari/review-rot then. Thanks.

Or shall we go deeper with dedicated classes for issues and pull-requests?

It would be great to do this. See this example

issue = Issue.get(1)
issue.change_status('closed')

similarly, if mapping supported issue operations to corresponding methods, for example,

• Issue.list: list project's issues
• Issue.comment: comment an issue
• PullRequest.close: close a pull request

and so on, it could give a clear view to libquery and much easier for use.

Hi,

since there is no progress on this, we started working on the code, that should solve this issue.

We have multiple python projects, that needs to communicate with the various git APIs (Github/Pagure/Giltab), so we decided to create one library, that has common API for multiple services (nowadays github and Pagure only):

https://github.com/user-cont/ogr

It's a fresh project, and the API will probably evolve, but I would like to know your ideas about the API and especially the relation to libpagure from the start.

In the case of pagure, we have the following approach:

• Class OurPagure that extends the libpagure functionality. (subclass of libpagure.Pagure class)
• On top of the OurPagure, we are implementing our abstract API. Pagure implementation is here.

We would like to share our code with other libpagure users. There are two approaches we can move the code here:

1. Move the code from OurPagure to libpagure
   • no dramatic changes, only small improvements
   • we need to implement two APIs to have it in the ogr API
2. Replace the libpagure with our new API:
   • better user-experience of the libpagure
   • completely different API, not compatible with current libpagure
   • easier evolution of new features -- we can work with pagure API dirrectly

Please, create issues to make the API better.

If you wish, I'll send a pull-request with the changes, but at first, I would like to discuss the best way to do it.

Thanks in advance for any ideas!

Replace the libpagure with our new API:
better user-experience of the libpagure
completely different API, not compatible with current libpagure
easier evolution of new features -- we can work with pagure API dirrectly

+1 to this idea, I think with the limited amount of API covered by the current code breaking the compatibility is not that bad, I also feel that not many people are using libpagure at the moment.

Please, create issues to make the API better.
If you wish, I'll send a pull-request with the changes, but at first, I would like to discuss the best way to do it.

Please do so I ll be happy to review the PR

Thanks in advance for any ideas!

Please do so I ll be happy to review the PR

Ok, I've started to work on this, but it will take me some time to merge the APIs. I'll try to send at least WIP version soon, so we can discuss the details there.

Hi,

I have finally some news about this. (Sorry for the delay...)

We found easier to incorporate the new design directly in the ogr. The code without libpagure was merged today so you can try it. (PyPI/rpm version will come soon.)

You can see the implementation here.

Please, try our approach and give us some feedback. (As a bonus, you have the same API for GitHub.)

Here is a short example of the usage:

from ogr.services.pagure import PagureService
from ogr.abstract import PRStatus

service = PagureService(token="???_PAGURE_TOKEN_???")

print(service.user.get_username())
project = service.get_project(repo="colin", namespace="rpms")
print(project.get_commit_statuses("339a19b0bbc766d0c6cdbbc2ef5a32c0de9f7551")[0])
print(project.get_tags())

print(project.is_forked())
fork = project.get_fork()
if not fork.exists():
    project.fork_create()
print(fork.exists())

for pr in project.get_pr_list(status=PRStatus.all):
    print("{} ({})".format(pr.title, pr.status.name))

pr = project.get_pr_info(3)
print(pr)
for c in project.get_pr_comments(3):
    print(c)

PRStatus, GitTag, CommitStatus, CommitComment, PullRequest, PRComment are still only "data classes". We are going to add methods for them as well. (Use my_pr.close() instead of my_project.pr_close(3).)