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

Remove experimental and unused [python-setup].requirement_constraints_target option and _python_constraints target #11998

Merged

Conversation

Eric-Arellano
Copy link
Contributor

@Eric-Arellano Eric-Arellano commented May 1, 2021

This was added in #11724 to support a macro for Poetry for constraints files. But we recently decided that the macro will not support automatically reading Poetry.lock because it is not very much to ask users to do poetry --export. The macro will only operate on pyproject.toml. As suggested in https://docs.google.com/document/d/1bCYb0UQZx9a-9tAagydCN_z3826QRvz_3aVnXKSNTJw/edit#heading=h.11w5a92c1zo8, (for now) the lockfile format will look like requirements.txt

This PR's reverted code diverges from the tool lockfile proposal and it's getting in the way.

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

…s_target` option and `_python_constraints` target

# 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 requested a review from benjyw May 1, 2021 01:31
@Eric-Arellano
Copy link
Contributor Author

Eric-Arellano commented May 1, 2021

@benjyw I think this is the right decision to revert..I'm trying to recall our exact rationale for why we will not attempt parsing Poetry.lock. Was it only to save time on implementation as it is reasonable to ask a user to run poetry export? Or there was a technical limitation?

Iirc, in the future we may want to support Poetry first-class for lockfiles, but it would look more robust than this. I think @stuhood has been saying that the macro might not be the best approach, and I could envision even doing something like Pants running a Poetry subprocess to run poetry export for you? I'm thinking best to start clean than go off this unused/shaky foundation?

FYI @wilsonliam, your thoughts welcome on this all :)

--

Also this is a little bit of a gray area with the deprecation policy in removing an option w/o deprecation. My thinking is that the help message noted it was experimental and it required use of a private API _python_constraints. Lmk if I need to deprecate though (hopefully with the option no-oping).

@benjyw
Copy link
Sponsor Contributor

benjyw commented May 1, 2021

Oh god I am not the right person to ask... I do not remember to this level of detail in this case.

@Eric-Arellano
Copy link
Contributor Author

Eric-Arellano commented May 1, 2021

Maybe we should wait to land this until I've fully sketched out what multiple lockfiles will look like (building off of Stu's proposal). Otherwise I think there's going to be too much churn.

@Eric-Arellano
Copy link
Contributor Author

Eric-Arellano commented May 6, 2021

While we're still finalizing some details from https://docs.google.com/document/d/1bCYb0UQZx9a-9tAagydCN_z3826QRvz_3aVnXKSNTJw/edit#, it's clear that this PR is regardless a good change to make. The proposal diverges a bit from what this PR reverts and keeping that code is noisy.

@Eric-Arellano Eric-Arellano requested a review from tdyas May 6, 2021 17:05
@Eric-Arellano Eric-Arellano merged commit 311419b into pantsbuild:main May 6, 2021
@Eric-Arellano Eric-Arellano deleted the revert-python-constraints-tgt branch May 6, 2021 17:58
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.

3 participants