Skip to content

Conversation

@ichard26
Copy link
Member

@ichard26 ichard26 commented Mar 28, 2025

See #13154 (comment).

This flag is way more prevalent than initially thought. Since this flag is already a no-op, it's better to hide it from CLI help. This way, we can avoid unnecessary churn, but avoid/discourage new occurances of the flag.

The deprecation has achieved the goal of communicating that this flag is
unnecessary today.

Supersedes and closes #13180.

@ichard26
Copy link
Member Author

FWIW, I'm borrowing the "soft-deprecated" terminology from CPython although the difference is that the API is already a no-op.

@ichard26
Copy link
Member Author

Actually, I guess it may be better to keep the test (or at least write a smoke test) to avoid someone else removing the flag by accident. Ugh, this deprecation was a mistake 🙃

@pfmoore
Copy link
Member

pfmoore commented Apr 1, 2025

@ichard26 are you still pushing for this to be in 25.1? It seems messy enough that maybe we just don't bother...?

@ichard26
Copy link
Member Author

ichard26 commented Apr 1, 2025

It seems messy enough that maybe we just don't bother...?

Don't bother with the deprecation? I'm in favour of reversing the deprecation, but I'd also prefer that people don't use this flag anymore (e.g., Hatch had specified this flag despite being written after the Python 2 days).

I think the deprecation has outlived its benefits so it's better to end it in 25.1 than 25.2 (and especially causing breakage by removing the flag outright). If this is too messy, we could literally just switch the flag help for SUPPRESS_HELP, make it clear within the code that's a legacy holdover, remove the deprecation warning, but otherwise do nothing.

This flag is way more prevalent than initially thought. Since this flag
is already a no-op, it's better to hide it from CLI help. This way, we can
avoid unnecessary churn, but avoid/discourage new occurances of the flag.

The deprecation has achieved the goal of communicating that this flag is
unnecessary today.
@ichard26 ichard26 force-pushed the removal/pythonwarning2 branch from 3ad6ab2 to bcc807f Compare April 1, 2025 21:22
@ichard26 ichard26 changed the title Remove docs/tests for --no-python-version-warning Reverse deprecation of --no-python-version-warning Apr 1, 2025
@pfmoore
Copy link
Member

pfmoore commented Apr 1, 2025

I meant just do nothing and go back to the status quo, but I'm OK with suppressing the help text.

@ichard26
Copy link
Member Author

ichard26 commented Apr 1, 2025

If the mythical Python 4 ever shows up and the flag becomes useful again, we can make the flag discoverable again. I think we have a good few years before that happens though 🙂

@ichard26
Copy link
Member Author

ichard26 commented Apr 3, 2025

While I'm here, I do want to apologise for this mess! It was poor judgment on my part to remove this flag. Consider it a learning experience that will remind me to remain conservative when in doubt.

@ichard26 ichard26 merged commit 258f95e into pypa:main Apr 3, 2025
29 checks passed
@ichard26 ichard26 deleted the removal/pythonwarning2 branch April 3, 2025 15:10
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 19, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants