Skip to content

Allow third-party versions to end in asterisk #6129

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Oct 10, 2021
Merged

Allow third-party versions to end in asterisk #6129

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
af8e2e9
Allow third-party versions to end in asterisk
srittau Oct 7, 2021
5f371f3
Update tests/stubtest_third_party.py
srittau Oct 8, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,15 +95,17 @@ The metadata file describes the stubs package using the
[TOML file format](https://toml.io/en/). Currently, the following keys are
supported:

* `version`: The latest version of the library that the stubs support.
* `version`: The versions of the library that the stubs support.
For libraries that reflect API changes in the version number only
the parts indicating the API level should be specified. In the case
of [Semantic Versioning](https://semver.org/) that is the first two
components. When the stubs are updated to a newer version
the parts indicating the API level should be specified, with an
asterisk representing the API-independent part. In the case
of [Semantic Versioning](https://semver.org/), this version could look
like this: `2.7.*`. When the stubs are updated to a newer version
of the library, the version of the stub should be bumped (note that
previous versions are still available on PyPI). Some legacy stubs are
marked with version `0.1`, indicating that their supported version is
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still have 0.1 stubs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#6094 removes the remaining ones.

unknown and needs to be updated.
unknown and needs to be updated. Other stubs don't use the asterisk
to denote the API-independent part.
Comment on lines +107 to +108
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to explain how the API-independent part works when there is no asterisk, but it doesn't really matter if this text will soon get revisited anyway.

* `python2` (default: `false`): If set to `true`, the top-level stubs
support both Python 2 and Python 3.
* `requires` (optional): A list of other stub packages or packages with type
Expand Down
2 changes: 1 addition & 1 deletion tests/check_consistent.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,7 +169,7 @@ def check_metadata():
assert "version" in data, f"Missing version for {distribution}"
version = data["version"]
msg = f"Unsupported Python version {version}"
assert re.match(r"^\d+\.\d+(\.\d+)?$", version), msg
assert re.match(r"^\d+(\.\d+)*(\.\*)?$", version), msg
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should 1 really be a valid version? How about 2.*?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until the transition is over, this is the safe thing to do, but we can remove it later. The dataclasses backport has version 0.1 upstream, which causes a lot of problems at the moment.

for key in data:
assert key in metadata_keys, f"Unexpected key {key} for {distribution}"
assert isinstance(data.get("python2", False), bool), f"Invalid python2 value for {distribution}"
Expand Down
7 changes: 5 additions & 2 deletions tests/stubtest_third_party.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,9 +47,12 @@ def run_stubtest(dist: Path) -> None:
pip_exe = str(venv_dir / "bin" / "pip")
python_exe = str(venv_dir / "bin" / "python")

dist_version = metadata.get("version")
if dist_version is None or dist_version == "0.1":
dist_version = metadata["version"]
assert isinstance(dist_version, str)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the assert belongs to check_consistent.py, not here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need it here for type checking purposes. But we should also check it in check_consistent.

if dist_version == "0.1":
dist_req = dist.name
elif dist_version.endswith(".*"):
dist_req = f"{dist.name}=={dist_version}"
else:
dist_req = f"{dist.name}=={dist_version}.*"

Expand Down