New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework GithubIntegration #2556
Rework GithubIntegration #2556
Conversation
f998c4e
to
881f560
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. One question about potentially API breaking changes though.
timeout=Consts.DEFAULT_TIMEOUT, | ||
user_agent=Consts.DEFAULT_USER_AGENT, | ||
per_page=Consts.DEFAULT_PER_PAGE, | ||
verify=True, | ||
retry=None, | ||
pool_size=None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an API breaking change if end users are using positional arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is right. The rational here is the jwt_*
arguments have been added quite recently and should be rarely used. So this breaks for little user code only, and is easy to fix. This will be flagged in the change log.
I favour similarity to github.Github
signature here over not breaking this API for everyone.
github/GithubIntegration.pyi
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a, relatively, small class, could we delete this pyi
file and move all the types over to the py
file since you're already touching this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to deal with that separately.
:param timeout: integer | ||
:param user_agent: string | ||
:param per_page: int | ||
:param verify: boolean or string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this document what values of verify
there are? I don't know why this would ever be a str
, or what values it would have
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I tracked it down. this eventually flows to requests.session
which takes the verify
argument and uses it. I understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this should reference requests.session
in the docs, maybe one day in the future.
self.assertEqual( | ||
kwargs.keys(), github.Requester.Requester.__init__.__annotations__.keys() | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good test!
881f560
to
494a930
Compare
Both
github.Github
andgithub.GithubIntegration
are main entry points of this library. They create aRequester
instance that handles all requests to the Github REST API. Requester has numerous arguments likebase_url
ortimeout
.Firstly,
Github
andGithubIntegration
should support the same (full) set ofRequester
arguments.Secondly, creating a
Github
instance for a Github App Installation coming fromGithubIntegration
should use the sameRequester
arguments (except forauth
). It should suffice to definebase_url
and other parameters once.Fixes issues like #2455.