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

Track Python indexes, find-links, and manylinux in lockfile headers #16525

Merged

Conversation

Eric-Arellano
Copy link
Contributor

@Eric-Arellano Eric-Arellano commented Aug 15, 2022

Closes #12832. It was a bug that changing [python-repos].{indexes,repos} and [python].resolver_manylinux did not invalidate lockfiles -- those options could impact the lock result!

V2 of lockfile metadata will continue to work the same as before. Next time someone runs generate-lockfiles though, they will get the new v3 lockfile header.

[ci skip-rust]
[ci skip-build-wheels]

# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
@Eric-Arellano Eric-Arellano added the category:bugfix Bug fixes for released features label Aug 15, 2022
@Eric-Arellano
Copy link
Contributor Author

Eric-Arellano commented Aug 15, 2022

This is the last thing we needed to track in lockfile header, so it's now safe to flip the switch to use v3 with generate-lockfiles.

This change is safe even if we continue switching the 3 options to be per-resolve. None of this code will need to change :)

@@ -111,14 +120,35 @@ def test_pex_lockfile_generation(
rule_runner: RuleRunner, no_binary: bool, only_binary: bool
) -> None:
args = ["--python-resolves={'test': 'foo.lock'}"]
only_binary_lock_str = '// "only_binary": [],\n'
Copy link
Contributor

Choose a reason for hiding this comment

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

Do only_binary / no_binary handle name normalization (I suspect not since the metadata types are set[str])? If not there is over-invalidation happening when someone switches from pantsbuild.pants to pantsbuild-pants even though both are the same and do not affect resolves.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They do not. Good point. I'll fix in a follow up :) #16527

@Eric-Arellano Eric-Arellano enabled auto-merge (squash) August 15, 2022 23:56
@Eric-Arellano Eric-Arellano merged commit c69a70c into pantsbuild:main Aug 16, 2022
@Eric-Arellano Eric-Arellano deleted the python-repos-lockfile-header branch August 16, 2022 00:24
cczona pushed a commit to cczona/pants that referenced this pull request Sep 1, 2022
…antsbuild#16525)

Closes pantsbuild#12832. It was a bug that changing `[python-repos].{indexes,repos}` and `[python].resolver_manylinux` did not invalidate lockfiles -- those options could impact the lock result!

V2 of lockfile metadata will continue to work the same as before. Next time someone runs `generate-lockfiles` though, they will get the new v3 lockfile header.

[ci skip-rust]
[ci skip-build-wheels]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bugfix Bug fixes for released features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lockfiles: figure out invalidation for additional_lockfile_args like manylinux
2 participants