-
-
Notifications
You must be signed in to change notification settings - Fork 614
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
Pass package_name
explicitly in click.version_option
decorators for compatibility with click>=8.0
#1400
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1400 +/- ##
=======================================
Coverage 99.67% 99.67%
=======================================
Files 34 34
Lines 3039 3041 +2
Branches 327 327
=======================================
+ Hits 3029 3031 +2
Misses 5 5
Partials 5 5
Continue to review full report at Codecov.
|
the failing mypy CI is due to click not being upgraded yet in typeshed. What do you think, should I add a |
Update: see python/typeshed#5503, this seems to be an issue with click directly. same questions still applies: ignore that typing or report to click. It seems that mypy is still catching up the old typeshed stubs instead of the new typing click8.0 provides. |
Click 8 provides typing directly, typeshed stubs are not used anymore. Not sure how the pre-commit mypy hook works, are you sure you're getting the latest click version in that environment? (By "you" I mean a pip-tools maintainer, not sure if you are one.) |
Hey @davidism , no I'm not a maintainer, just wanted to contribute something here :) I can reproduce the issue with pre-commit.ci locally, but the corresponding virtualenv mypy is using seems to use click 8, so I have no idea why the click typing is not used. Would definitely appreciate the support of some maintainer here debugging the issue, maybe this is something more trivial than it looks to me. |
Hey, are any maintainers around here and reading this? It seems that the pre-commit CI is optional for merging, would be great to get some comment on whether it's preferred to first merge that or first fix the failing CI job. Regarding the mypy hook (the failing one): it seems that |
Aw, that makes sense now, since we cache installed dependencies in CI. @webknjaz Is there a decent way to drop the cache (other than update the cache key or example)? |
Still, there would be other errors introduced then with the new click version: I'd open a separate ticket for that, would you agree with that procedure? |
Yeah, let's track this in a separate issue. Thanks! In addition to click, I'm inclined to think that the latest pip update brought new types and we need to address that also. |
Not that I know of. Although, you seem to be assuming the wrong check. The one that is failing is not coming from GHA. It comes from the pre-commit.ci service. |
The newest pre-commit ci run seemed to use the proper version and raised the same errors I experienced when explicitly adding the new dependency (compare #1401 and #1402 ). I'd say this can be merged while ignoring the failing pre-commit.ci check, what do you think @webknjaz ? Well, just realized that it would make sense to then upgrade install_requires to click >= 8 as well, as the option was introduced there. Anything speaking against that? |
Yes, unless we want to have broad compatibility with older click, we should bump the dep too. Regarding broken typing, if it's directly connected to this change, it must be fixed as a part of it. |
will bump the dependency then. Regarding the typing: no, it's due to new click and is on latest pre-commit-CI as well, this just didn't had it due to some caching apparently. Would be solved in #1402 . |
But bumping click is directly related to this then. This PR cannot be accepted with breaking typing. |
Sorry, that was a typo... I wanted to write that it's due to new pip version - so not related in any way to click and the current CI setup is broken with the same errors if running now as well already (as you can see in #1401 ). |
Oh, I misunderstood that. Thinking more about dropping the older click, I think it's probably preferable to support those. This is because click is fairly popular and there's a good chance that some users will have other tools in the same env that may pin click more strictly and so it's a potentially serious conflict we'd cause. |
fair point, but not sure how to handle as the current setup is broken sometimes under click 8. Made some inline suggestion in the code to keep click 7 but handle 8 separately then. |
There's a few ways: ver_kwargs = {} if click7 else {'package_name': 'piptools'}
...
@click.version_option(**ver_kwargs)
def cli(...): ... ...
def cli(...): ...
if click8:
cli = click.version_option(package_name='piptools')(cli) from itertools import partial
ver_opt = click.version_option if click7 else partial(click.version_option, package_name='piptools')
...
@ver_opt()
def cli(...): ... |
That's what I suggested, sorry if that was not clear :-) was just waiting for the okay to do this version-based differencing, would implement option 1 then. Thanks! |
…ersion_option arguments to click
for more information, see https://pre-commit.ci
from .pip_compat import PIP_VERSION, parse_requirements | ||
|
||
__all__ = ["PIP_VERSION", "parse_requirements"] | ||
__all__ = ["PIP_VERSION", "IS_CLICK_VER_8_PLUS", "parse_requirements"] |
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.
Side note: why is this a list? It's usually recommended to make __all__
immutable, hence use a tuple.
P.S. This is out of the scope of this PR, just wanted to make a note.
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.
to be fair, this is a list as well in the python tutorial on modules: https://docs.python.org/3/tutorial/modules.html#importing-from-a-package and the pip package has this format as well.
Do you want to change this here or should I leave as it is? I actually don't have any preference here.
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.
No, don't touch this because it's out of the scope. But in the future, this should probably be added. I've added this comment for history.
P.S. Normally, pylint would warn about this problem but I don't think it's integrated.
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.
at least pycodestyle seems to do so, compare PyCQA/pydocstyle#62
piptools/_compat/click_compat.py
Outdated
@@ -0,0 +1,5 @@ | |||
import click | |||
from pip._vendor.packaging.version import Version |
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 really like relying on how and whether pip vendors its deps. Plus it may cause problems when repackaged in distros that unbundle vendored software.
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.
sure, was just in analogy to pip_compat
module - would you agree with using int(click.__version__.split(".")[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.
Yeah, that should be 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.
Although, you may want to multi-line it to keep the inline complexity low
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.
not sure what you mean with multi-lining, as for me black would merge this into one line if not forcing to not do on the following:
int(
click.__version__.split(".")[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.
nvmd, will simply add a comment then in between the brackeets
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.
Yeah, that's one of the reasons I dislike black...
As for the line complexity, I like this metric that https://wemake-python-stylegui.de introduced called Jones complexity. It really makes a difference maintainability/readability-wise!
Here's some more info on this https://sobolevn.me/2019/10/complexity-waterfall#lines.
I wish this set of linter plugins was integrated here.
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.
didn't knew the blog entry regarding the complexity until now, found it a good read and would recommend to colleagues, thanks a lot for that, very interesting!
Hey @webknjaz thanks for your patience with me during this PR! For me it looks like it is ready to get into a next release. Whats the progress from here? would you merge it to master directly and/or add a milestone (I am not able to do any of those two)? And do I have to do anything from my side or does everything look good now? Update: ... at least regarding the milestone I made it :) |
So it looks like the CI is failing because of an unrelated problem so that would need to be fixed before merging this PR. Regarding the release, I don't do those so you'll have to wait. |
Alright, would wait then, thanks for the information! Yes, for the CI there is issue #1403 . |
Hey @webknjaz , as you already reviewed this I'd merge it, but I'm not sure if this is only fine for more senior persons on the project. Should I proceed or do you / others want to keep the hands on what gets to the main branch? |
@nicoa feel free to merge |
It looks like the ternary was committed backwards in #1400, since the `package_name` option was add in click 8, but is only being passed in click 7. That caused `pip-tools` to error on import when installed alongside click 7.
package_name
explicitly in click.version_option
decorators for compatibility with click>=8.0
It looks like the ternary was committed backwards in jazzband/pip-tools#1400, since the `package_name` option was add in click 8, but is only being passed in click 7. That caused `pip-tools` to error on import when installed alongside click 7.
Closes #1398 .
Unfortunately mypy threw some errors during pre-commit run, where two of them seem to be valid (coming from CI as well).
Further, some of the tests failed, but this seems to be related to a pip.conf file adding extra indices to the compiled requirements, I'll re-run them again to see if this is related.
Changelog-friendly one-liner: pass package_name explicitly in click.version_option decorators for compatibility with click>=8.0
Contributor checklist