Visually separate PyPy interpreter version from name

[brettcannon]

The interpreter tag of pp370 looks like (at least to me) that this is PyPy for Python 3.7.0 which isn't accurate: it's actually PyPy3 7.0. If the name was changed to pp3_70 it would be more obvious this is about PyPy3 7.0.

@mattip would PyPy like to see this change? We would emit tags for both pp370 and pp3_70 for a while to keep compatibility to give a clear, easy, long transition.

[mattip]

I assume you are referring to the PEP425 python tag. It is documented as py_version_nodot, so IMO it should be pp3 or pp36 or pp37 (for python 3.6 and python 3.7 respectively). The current value of pp370 is indeed very confusing.

The pypy version (currently 7.2.0 or 7.2.1) is only relevant for the C-API, python compatibility should only be dictated by the sys.version_info numbers. The current active version of PyPy is python3.6 compatible, we will be releasing a python3.7 probably early in 2020.

The ABI tag is very different, but only needed for c-extension packages. The PEP states "Each implementation's community may decide how to best use the ABI tag.", and I think the PyPy community is zeroing in on a tag that combines the sys.version_info[:2] with sys.pypy_version_info[:2] so something like pypy36_pp72. I say "zeroing in" because we recently noticed problems with the way pep425.py produces the ABI tag on windows. For instance, the wheels for pillow use Pillow-6.1.0-pp370-pp370-win32.whl where the ABI tag is the same as the python tag. This is different from linux wheels, which use numpy-1.17.3-pp372-pypy3_72-manylinux2010_x86_64.whl. We have solved this (a few hours ago, actually) by emitting a value for sysconfig.get_config_var('SOABI') on windows, like on linux.

We currently do not have a "stable API" story; wheels must be recreated for each python version of every pypy release.

[brettcannon]

@mattip you're correct this is all about PEP 425 tags.

As of right now the PyPy interpreter is determined by:

packaging/packaging/tags.py

Lines 183 to 191 in bb80ca7

	def _pypy_interpreter():
	# type: () -> str
	# Ignoring sys.pypy_version_info for type checking due to typeshed lacking
	# the reference to the attribute.
	return "pp{py_major}{pypy_major}{pypy_minor}".format(
	py_major=sys.version_info[0],
	pypy_major=sys.pypy_version_info.major, # type: ignore
	pypy_minor=sys.pypy_version_info.minor, # type: ignore
	)

and not py_version_nodot (that's the fallback when a more specialized approach is not available for an interpreter). This was taken directly from what pip does today. Should this be changed to be:

packaging/packaging/tags.py

Lines 462 to 467 in bb80ca7

	def _generic_interpreter(name, py_version, warn=False):
	# type: (str, PythonVersion, Optional[bool]) -> str
	version = _get_config_var("py_version_nodot", warn)
	if not version:
	version = "".join(map(str, py_version[:2]))
	return "{name}{version}".format(name=name, version=version)

instead/as well?

Right now the ABI is determined by the SOABI config value:

packaging/packaging/tags.py

Lines 194 to 200 in bb80ca7

	def _generic_abi():
	# type: () -> str
	abi = sysconfig.get_config_var("SOABI")
	if abi:
	return _normalize_string(abi)
	else:
	return "none"

[mattip]

+1 from me for the changes going forward. But _generic_abi() will always return none on current pypy releases on windows. What is the timeline for releasing this package as part of pip/setuptools instead of pep425.py? We intend to release a pypy with the fix to sysconfig.get_config_var("SOABI") soonish. How soon should "soonish" be?

[brettcannon]

@mattip For when this will land in pip, #231 has to get merged first and probably a bugfix or two need to get fixed, and then a pip developer has to pull it in which probably depends on when someone like @chrahunt gets to it. So I personally don't have a timeline and I don't think anyone else does either; it's just "when it's ready".

In regards to your "+1 for the changes going forward", is that to use _generic_interpreter() instead of _pypy_interpreter() to get the interpreter name? IOW in #231 that would mean dropping pypy_tags() and just using generic_tags() as the interpreter name is the only difference right now. And BTW I think that SOABI change will fix #184 will it not?

[mattip]

+1 for dropping _pypy_interpreter in favor of _generic_interpreter, and just using generic_tags. I commented on #184, thanks for helping us work through that.

[xavfernandez]

How soon should "soonish" be?

If everything goes smoothly (and I see no reason it shouldn't) this will be in next pip version 20.0 which should be released in January 2020.

[brettcannon]

@mattip thanks for the feedback! I will fix #231 and drop pypy_tags() in favour of generic_tags() before it gets merged.

[mattip]

@brettcannon Thanks for making sure pypy is supported.

[brettcannon]

I've dropped the PyPy-specific code from #231 , so I'm going to go ahead and close this issue.

[ncoghlan]

We missed the step of getting wheel to stop generating the custom PyPy interpreter tag: pypa/wheel#329

(Edit: this was actually resolved in pypa/wheel#328, there was just one harmless lingering reference to the old custom tagging in the code)