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

Reduce pytest warnings to zero #2707

Conversation

pseudo-rnd-thoughts
Copy link
Contributor

As I noted in #2602, it would be nice if the pytest warnings were thrown as errors so if new changes caused issues
Building upon #2602 that updated the CI and #2703 that fixed warnings (but hasn't been PR yet)

This fixes all warnings from #2660, mostly through added filterwarnings to prevent the warnings from being thrown

kir0ul and others added 23 commits March 15, 2022 19:03
- Remove `lint_python` CI job
- Move `pyupgrade` job to `pre-commit` workflow
…er.py by using the self._frames_per_sec value as default value if video.frames_per_second is missing
… video.output_frames_per_seconds are the updated frames_per_sec and output_frames_per_sec values
…ime steps (this happened with CartPole), if step is done then reset the environment

_check_box_obs, fixed spelling of maxmimum to maximum for ignoring the warning
…that produce a single element (not an array as contains expected)
@kir0ul
Copy link
Contributor

kir0ul commented Mar 21, 2022

I'm not sure it's a good idea to transform warnings into errors, I think warnings and errors are two different things and having the flexibility of allowing warnings to pass the CI can sometimes be a good thing.
One concrete example could be that someone is working on a feature and gets a deprecation warning. Since this warning has become an error, CI will not pass, and they'll have to fix the warning to make it pass. But maybe this deprecation warning should be fixed in its own dedicated issue as it could impact other things which are independent of the feature they're working on.
I think we should tend to zero warning, but we should allow warnings to pass the CI in case there's the need for some flexibility.

@pseudo-rnd-thoughts
Copy link
Contributor Author

Thanks for the comment. I agree with you but in your example, couldn't they just create a separate PR to address the DeprecatedWarnings? Do you think we should only be throwing errors for user warnings?
I included DeprecationWarnings because when I was doing #2660 a majority of the warnings I was getting were DeprecationWarnings and can be the most critical if left unchanged for a long period of time.

@pseudo-rnd-thoughts pseudo-rnd-thoughts marked this pull request as draft March 21, 2022 12:41
@pseudo-rnd-thoughts
Copy link
Contributor Author

Im setting this as a draft because it requires #2602 and #2703 to be merged first

# Conflicts:
#	.pre-commit-config.yaml
#	CONTRIBUTING.md
#	gym/envs/classic_control/acrobot.py
#	gym/envs/toy_text/blackjack.py
#	gym/envs/toy_text/frozen_lake.py
#	gym/wrappers/__init__.py
# Conflicts:
#	.pre-commit-config.yaml
#	CONTRIBUTING.md
#	gym/envs/classic_control/acrobot.py
#	gym/envs/toy_text/blackjack.py
#	gym/envs/toy_text/frozen_lake.py
#	gym/wrappers/__init__.py
…pytest-warnings-to-errors

# Conflicts:
#	gym/envs/toy_text/blackjack.py
@pseudo-rnd-thoughts pseudo-rnd-thoughts marked this pull request as ready for review April 2, 2022 15:08
@pseudo-rnd-thoughts
Copy link
Contributor Author

With #2602 and #2703 merged, the PR is ready for review @jkterry1
Would this PR be of interest? It should help prevent warnings being thrown and not being fixed

@kir0ul
Copy link
Contributor

kir0ul commented Apr 6, 2022

I agree with you but in your example, couldn't they just create a separate PR to address the DeprecatedWarnings?

Yes they could, but maybe they're working on something unrelated to this warning, which could be fixed in its own specific PR.

Do you think we should only be throwing errors for user warnings? I included DeprecationWarnings because when I was doing #2660 a majority of the warnings I was getting were DeprecationWarnings and can be the most critical if left unchanged for a long period of time.

IMHO I don't think we should force any warnings to become errors. I agree those are annoying but I think the situation you're referring to was different as we got all those warnings at once because of a bug in pytest-forked. Usually warnings would grow slowly and can be corrected as they appear. Of course we should fix all those DeprecationWarning but we can also live with a DeprecationWarning for a short amount of time if for any reason we need time to fix it.
As another example, let's say we find another bug and get another time 1500 warnings all at once, if they are now converted to errors you wouldn't have been able to fix them in several chunks as you did.

Also I don't know if you saw that but there's now a checkbox in the PR template so that developers keep in mind to check for new warnings.

@pseudo-rnd-thoughts
Copy link
Contributor Author

pseudo-rnd-thoughts commented Apr 6, 2022

Thanks for the feedback @kir0ul, I agree that this is an important PR that we should consider carefully before merging and I think it would be reasonable not to do so. However, I think there are several important advantages to it

maybe they're working on something unrelated to this warning, which could be fixed in its own specific PR.

I agree with this however, if it is a separate issue, then it would naturally make sense for another PR to make such changes. Or if necessary I believe a force merge could ignore the failing tests

As well, as this commit, sets the number of warnings to zero, then any new warnings that arise should be caused by the changes made by the PR. Meaning that the PR would address their own issues.

This is one of the advantages of stopping warnings early is that the person causing the issue, also has to solve them. Rather than waiting for a while before fixing, by possibly someone new who may misunderstand the original code or the original author who may have forgotten their implementation.

let's say we find another bug and get another time 1500 warnings all at once, if they are now converted to errors you wouldn't have been able to fix them in several chunks as you did.

This is fair, but as I explained above, I think that is very unlikely get ~1500 warnings again, due to eliminating them as they occur and that they would only have to address the warnings caused by themselves most likely.

warning checkbox in the PR template

I hadn't noticed that changes, thanks for doing that, the problem is that the github build actions don't show the number of warnings so it is easy to forget to check if the person has removed warnings. Allowing the number of warnings to increase again, causing the issue above.

Is there something I missing? If this is too radical a change to make then I can understand if we don't want to move forward with this PR

@jkterry1
Copy link
Collaborator

@pseudo-rnd-thoughts could you please fix merge conflicts?

@pseudo-rnd-thoughts pseudo-rnd-thoughts changed the title Pytest warnings to errors Reduce pytest warnings to zero Apr 13, 2022
@pseudo-rnd-thoughts
Copy link
Contributor Author

@kir0ul Talking to @jkterry1, while I still think that the idea of reducing warnings is good, this method of doing it could cause too many issues to be helpful.
I have removed the warnings to errors part and removed some additional warnings that I found such that the number of warnings should be now 0!

@jkterry1
Copy link
Collaborator

Hey, I'm closing this per our discussion, please create a new PR with the changes that are still needed

@jkterry1 jkterry1 closed this Apr 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants