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

feature request: normalized pep440 check #179

Open
trim21 opened this issue Jun 5, 2024 · 6 comments
Open

feature request: normalized pep440 check #179

trim21 opened this issue Jun 5, 2024 · 6 comments

Comments

@trim21
Copy link

trim21 commented Jun 5, 2024

pep440 provice a lax regex and a canonical regex, could we have a strict version check with canonical regex?

which mean, under this checking 0.0.1.a0 is invalid, and it's normalized result 0.0.1a0 is valid.

This can be done with packaing package https://github.com/pypa/packaging/blob/main/tests/test_version.py

import packaging.version

def normalized_pep440(s: str):
    assert s == str(packaging.version.Version(s))

I can send a pr for this.

@abravalheri
Copy link
Owner

Hi @trim21, sorry for the delay, this slipped under the radar.

I believe it would be fine to add this custom format that you propose. The only thing is that packaging is an optional dependency, so there should be a contingency in the case it cannot be imported. Are you planning to use this format in a plugin?

Another nitpick I personally have is the terminology: I agree that 0.0.1.a0 is not a normalised version according to PEP 440, but I don't know if we can actually say they are invalid in a strict sense (the PEP specifically say they must be considered when parsing a version, so strictly speaking they are valid). Maybe the custom format should be named normalized_pep440?

@trim21
Copy link
Author

trim21 commented Oct 16, 2024

Hi @trim21, sorry for the delay, this slipped under the radar.

I believe it would be fine to add this custom format that you propose. The only thing is that packaging is an optional dependency, so there should be a contingency in the case it cannot be imported. Are you planning to use this format in a plugin?

Another nitpick I personally have is the terminology: I agree that 0.0.1.a0 is not a normalised version according to PEP 440, but I don't know if we can actually say they are invalid in a strict sense (the PEP specifically say they must be considered when parsing a version, so strictly speaking they are valid). Maybe the custom format should be named normalized_pep440?

OK, calling it normalized-pep440 make more sense.

This would require some kind of configuration to enable it, I think. otherwise users with [all] will get unexpected failure.

For example, a arguments --normalized-pep440 and when it's enabled, if packaging are missing, raise a error about that, then if version is not normalized, raise another error.

@trim21 trim21 changed the title feature request: strict pep440 check feature request: normalized pep440 check Oct 16, 2024
@trim21
Copy link
Author

trim21 commented Oct 16, 2024

or we can just make packaging required by default, and replace VERSION_PATTERN with packaging.version.Version

@henryiii
Copy link
Collaborator

If I remember correctly, this is integrated in setuptools, and so cannot have any required dependencies.

@henryiii
Copy link
Collaborator

I like the idea of a general —-strict flag though that require everything be normalized (like extras) and maybe requires all the optional components are available, like the trove classifiers.

@trim21
Copy link
Author

trim21 commented Oct 16, 2024

If I remember correctly, this is integrated in setuptools, and so cannot have any required dependencies.

OK, so make this flag only works when packaging installed, and throw a error if it's enabled and required deps not installed, including packaing and trove classifiers

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

No branches or pull requests

3 participants