-
Notifications
You must be signed in to change notification settings - Fork 55
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
Enforce strict Optional typing #723
base: main
Are you sure you want to change the base?
Conversation
Build failed. ✔️ pre-commit SUCCESS in 1m 59s |
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.
Some of these fixes are not perfect
I see, it's been clear to me that the --no-strict-optional removal would mean some compromises.
TODO: regenerate some requre responses (the failing tests). I may need some help with this,
I'll try, but don't promise anything (I usually try to avoid this :-) )
I'll have a look. BTW it kinda bothers me that you need to regenerate data after typing-related changes :D |
@@ -332,6 +332,8 @@ def project_create( | |||
parameters["description"] = repo | |||
if namespace: | |||
parameters["namespace"] = namespace | |||
else: | |||
namespace = self.user.get_username() |
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.
@mfocko in some cases, changing the code rather than the typing just seemed like the more correct solution. This is one of the places which causes the tests to fail. If namespace
is not provided, it seems to assume the current authenticated user and fills it in automatically. However, PagureProject
constructor requires namespace. If I hadn't added this extra call (which obviously creates the need for test data regeneration), the only solution would be to make namespace
inside PagureProject
Optional
which does not seem right.
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.
yup, some of those Optional
s are quite suspicious
@@ -217,7 +217,7 @@ def body(self, new_body: str) -> None: | |||
self._body = new_body | |||
|
|||
@property | |||
def id(self) -> int: | |||
def id(self) -> Optional[int]: |
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.
Does it make sense though?
I think I know what you meant in the description.
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 is a bit of a dilemma. It doesn't make much sense semantically, however just based on our interface, this could happen. If I wanted to enforce an int
here, the order of arguments in the constructor would have to be changed (along with some other changes of course)
@@ -10,7 +10,9 @@ | |||
|
|||
|
|||
class TokenAuthentication(GithubAuthentication): | |||
def __init__(self, token: str, max_retries: Union[int, Retry] = 0, **_) -> None: | |||
def __init__( | |||
self, token: Optional[str], max_retries: Union[int, Retry] = 0, **_ |
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.
oh no, memories of this magic are coming back /o\
@@ -104,6 +104,8 @@ def project_create( | |||
except gitlab.GitlabGetError as ex: | |||
raise GitlabAPIException(f"Group {namespace} not found.") from ex | |||
data["namespace_id"] = group.id | |||
else: | |||
namespace = self.user.get_username() |
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 one is breaking tests, right?
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 don't think so, only 4 pagure tests are failing right now. Perhaps getting the username was cached in the requre test data...
@@ -150,10 +150,11 @@ def create( | |||
} | |||
|
|||
caller = project | |||
if project.is_fork: | |||
if project.is_fork and caller.parent: |
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.
tbf, this could break tests too, because you need to query both is_fork
and parent
, and on the background it may be 2 separate API calls, even though one is enough :/
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 breaks something too IIRC.
Oh, only 4 tests? I expected worse 😁 |
Signed-off-by: František Nečas <fnecas@redhat.com>
Signed-off-by: František Nečas <fnecas@redhat.com>
I've resolved some of the issues pointed out in the review, however I am still a bit unsure about the correct solution in some of the weird cases. |
Build failed. ✔️ pre-commit SUCCESS in 2m 41s |
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.
Wow, thanks so much for all the work!
- Pagure: namespace (e.g. `"rpms"`). | ||
- Pagure: namespace (e.g. `"rpms"`). May be `None`, i.e. no namespace present. |
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.
What about using an empty string for this?
(I am looking at that from the GitLab
perspecive where you can have "one_namespace"
, "two/namespaces"
, so why not ""
.)
I know, it's a functional change...;)
I think one of the issues with types is that we were using some of the »abstract« classes in the test cases all over the codebase of packit(-service), which makes the typing more complicated. IMO in ideal case we should have everything hidden behind a property, so that we can handle it from specific git-forge and maybe have a „dummy“ classes for tests. However that will involve breaking of a lot of rev-dep tests and seems, at least to me, time-consuming to fix everywhere :/ |
This issue has been marked as stale because it hasn't seen any Stale issues are closed after 14 days, unless the label is removed This is done in order to ensure that open issues are still relevant. Thank you for your contribution! 🦄 🚀 🤖 (Note: issues labeled with pinned or EPIC are |
This issue has been marked as stale because it hasn't seen any Stale issues are closed after 14 days, unless the label is removed This is done in order to ensure that open issues are still relevant. Thank you for your contribution! 🦄 🚀 🤖 (Note: issues labeled with pinned or EPIC are |
Some of these fixes are not perfect, in a few places I added
Optional
where I feel it shouldn't really be. However, it's not really possible any other way without significant refactoring which would break the API (which I don't want to do). Sometimes a specific forge may returnNone
so it was necessary to update the type of the abstract class.I tried to not make any functional changes, most of these are just to align the typing with the actual implementation.
TODO:
Fixes #696
Related to #251
Merge before/after