Deprecate and remove --no-python-version-warning as Python 2 is dead

[ichard26]

The Python 2 days are behind us, thus we can kill off the --no-python-version-warning flag which disabled the "Python 2 is sunsetting support" warnings :)

If you're using this flag, you can simply stop. It does nothing today.

[jsirois]

FWIW the help text says nothing at all about Python 2 and suggests the option is useful today to - for example - warn that Python 3.8 support is going away:

pip/src/pip/_internal/cli/cmdoptions.py

Lines 987 to 994 in 0d609f7

	no_python_version_warning: Callable[..., Option] = partial(
	Option,
	"--no-python-version-warning",
	dest="no_python_version_warning",
	action="store_true",
	default=False,
	help="Silence deprecation warnings for upcoming unsupported Pythons.",
	)

[ichard26]

Yeah.. we've never done that other than for the Python 2 sunset. We could start warning, but seems unnecessary, especially as we're more on the conservative side when it comes to dropping Python versions. Once we drop a Python version, it probably has fallen out of major use (and the folks still using it can't be using the latest and greatest for other parts of the ecosystem already).

[basnijholt]

One issue will be that libmamba, which is used in the entire conda ecosystem was using this flag until 2 weeks ago: https://github.com/mamba-org/mamba/pull/3770/files

I suspect this is going to cause a lot of issues for folks that don't update their Conda / Mamba / micromamba.

[pfmoore]

If they are using the environment variable (which is what it looks like), it'll just get ignored.

[ichard26]

OK, more people are relying on this flag than I thought. I still want people to stop using it as it does nothing, and I suspect that the modern uses of the flag (e.g., Hatch) are due to the reasonable but wrong assumption it still does something (another reason to remove it). However, we could probably just hide the flag from our help output, remove the tests, but otherwise leave the flag be as a no-op.

I'd rather not cause churn over this. Thoughts?

[jaraco]

I'm in favor of removing it, but also not breaking things. It's a difficult tradeoff. Some churn is going to be required to remove it. It looks like at least some people are addressing the deprecation. My instinct is that it can be removed with modest churn, but maybe not in 25.1.

[pfmoore]

Let's stick to our standard deprecation period of 6 months and remove in 25.2. There's no rush. But equally, there's no reason to extend beyond our standard 6 months.

[ichard26]

Hi all, I've since realized that fully removing this flag would be more disruptive I initially thought.

I propose that we simply remove the tests and documentation for the flag. It's already a no-op so there's no point to break people who are passing it for legacy reasons. That we can minimize the code we're maintaining, but also avoid unnecessary breakage (which I'd like to avoid, especially in light of the setuptools fiasco).

#13308

[piotr-dobrogost]

@ichard26

especially in light of the setuptools fiasco

I've been not followng pip for a while. What fiasco do mean here?

[ichard26]

Setuptools has recently made a string of backwards incompatible changes/removals that have caused considerable breakage. The community backlash has spilled beyond setuptools' issue tracker. If you're interested, you can take a look at the most recently active issues on setuptools. The specifics aren't important (and I'd rather not bring over discussions being held on setuptools here).