Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

FrNecas
Copy link

@FrNecas FrNecas commented Jul 14, 2022

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 return None 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:

  • regenerate some requre responses (the failing tests). I may need some help with this, I managed to do this for one of the failing tests but not for the repo creation yet.

Fixes #696

Related to #251

Merge before/after

@FrNecas FrNecas changed the title Frnecas typing Enforce strict Optional typing Jul 14, 2022
@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

✔️ pre-commit SUCCESS in 1m 59s
ogr-tests-rpm FAILURE in 6m 09s
ogr-tests-pip-deps FAILURE in 6m 26s
✔️ ogr-reverse-dep-packit-tests SUCCESS in 13m 05s

Copy link
Member

@jpopelka jpopelka left a 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 :-) )

@mfocko
Copy link
Member

mfocko commented Jul 18, 2022

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()
Copy link
Author

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.

Copy link
Member

@mfocko mfocko left a 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 Optionals 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]:
Copy link
Member

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.

Copy link
Author

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)

ogr/abstract.py Outdated Show resolved Hide resolved
ogr/parsing.py Outdated Show resolved Hide resolved
@@ -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, **_
Copy link
Member

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\

ogr/services/github/flag.py Outdated Show resolved Hide resolved
ogr/services/pagure/release.py Outdated Show resolved Hide resolved
ogr/services/github/release.py Show resolved Hide resolved
ogr/services/gitlab/issue.py Outdated Show resolved Hide resolved
@@ -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()
Copy link
Member

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?

Copy link
Author

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:
Copy link
Member

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 :/

Copy link
Author

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.

@mfocko
Copy link
Member

mfocko commented Jul 18, 2022

Oh, only 4 tests? I expected worse 😁

František Nečas added 3 commits July 28, 2022 09:11
Signed-off-by: František Nečas <fnecas@redhat.com>
Signed-off-by: František Nečas <fnecas@redhat.com>
@FrNecas
Copy link
Author

FrNecas commented Jul 28, 2022

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.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

✔️ pre-commit SUCCESS in 2m 41s
ogr-tests-rpm FAILURE in 7m 07s
ogr-tests-pip-deps FAILURE in 7m 05s
✔️ ogr-reverse-dep-packit-tests SUCCESS in 14m 09s

Copy link
Member

@lachmanfrantisek lachmanfrantisek left a 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!

Comment on lines -1338 to +1344
- Pagure: namespace (e.g. `"rpms"`).
- Pagure: namespace (e.g. `"rpms"`). May be `None`, i.e. no namespace present.
Copy link
Member

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...;)

@mfocko
Copy link
Member

mfocko commented Jul 28, 2022

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.

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 :/

@stale
Copy link

stale bot commented Oct 30, 2022

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

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
never marked as stale.)

@lachmanfrantisek lachmanfrantisek mentioned this pull request Dec 7, 2022
@stale
Copy link

stale bot commented Jan 7, 2023

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

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
never marked as stale.)

@stale stale bot added the stale Is the issue still valid? label Jan 7, 2023
@jpopelka jpopelka mentioned this pull request Sep 26, 2023
@mfocko mfocko added the 🌞 friday 🤟 Weekend is coming! label Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🌞 friday 🤟 Weekend is coming! stale Is the issue still valid?
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Run mypy without --no-strict-optional
4 participants