This is related to #147, but not quite since I want to go beyond validation and have read/write support for things like TOML, METADATA, etc.

I see two potential API forms. One is a dataclass-like object that stores the data with some methods to help read/write to various formats. The other form is a dict with various functions to manage the reading/writing.

I actually think the dict approach might be the best and easiest to work with for two reasons. One, I don't see anything inherent in the potential design that will require OOP (i.e. method overriding to influence results). I have not thought of an API that would call other methods where overriding would be necessary.

Two, it makes representing the explicit lack of data versus what goes into dynamic ala PEP 621 more obvious. If the lack of a key means "information is explicitly not provided", then that can be expressed in a dict. If we make the existence of a key with a None value represent something that would go into dynamic, then we don't have to maintain dynamic details separately. Using a dataclass doesn't buy us anything over this as it makes representing no data a little trickier as we would have to add some way to delineate that (e.g. some other false value that isn't None?). Best benefit to a dataclass I can think of is a property to dynamically calculate dynamic (😁 ) which could also be done with a function.

There's also no loss in typing as a partial TypedDict would work in this instance.

So for me, the simplicity of using a dict for storing data in the appropriate formats and using the lack of key to delineate purposefully missing data is the way to go.

Fixes #606 where PyPy would like to change its non-compliant SOABI tag (pypy36-pp73) to a compliant one (pypy39-pp73-x86_64-linux-gnu).

The basic code is ~taken from wheel.bdist_wheel's version.~ changed to use EXT_SUFFIX instead of SOABI.

A few other changes:

• return a list instead of a iterator, since all uses of the function converted to a list anyway ~- add a fallback for older cpython to call _cpython_abis, which means passing in PythonVersion~
• clarify the typical value of interpreter_name, since it actually is the 'cp' or 'pp' short name.

If I was starting over, PyPy's ABI tag would be pp39_73 rather than pypy39_73 to save two letters. Maybe someday ...

Edit (11-Nov-2022): refactored to use EXT_SUFFIX

@pypa/packaging-committers Any concerns with me putting on the RM hat for making this release, and cutting it sometime in the next few weeks?

I think we can make this, once #484 merges.

/cc @sbidoul, to flag that I'd like this to be in time for pip 22.2. :)

This updates packaging to know about Mac OS version 11.0, which supports both x86_64 and arm64 arches.

It will allow pip to install x86_64 wheels built for previous versions of Mac OS onto 11.0

see: https://github.com/pypa/packaging/issues/318 see: https://discuss.python.org/t/apple-silicon-and-packaging/4516 see: https://github.com/python/cpython/pull/21246

Provide an adequate platform tag for AIX. The generic tag provided by distutils.util.get_platform() is insufficient - besides missing "bitness" it does not provide any information regarding Technology Level, nor build date.

xref gh-280. This adds a whole bunch of PEP 600 tags (my python reports `os.confstr('CS_GNU_LIBC_VERSION') of 2.27): EDIT: after reversing the order in f432bcd93f4

>>> from packaging import tags
>>> print ('\n'.join([str(t) for t in tags.sys_tags()]))
cp37-cp37m-manylinux_2_27_x86_64
cp37-cp37m-manylinux_2_26_x86_64
cp37-cp37m-manylinux_2_25_x86_64
cp37-cp37m-manylinux_2_24_x86_64
cp37-cp37m-manylinux_2_23_x86_64
cp37-cp37m-manylinux_2_22_x86_64
cp37-cp37m-manylinux_2_21_x86_64
cp37-cp37m-manylinux_2_20_x86_64
cp37-cp37m-manylinux_2_19_x86_64
cp37-cp37m-manylinux_2_18_x86_64
cp37-cp37m-manylinux_2_17_x86_64
cp37-cp37m-manylinux2014_x86_64
cp37-cp37m-manylinux_2_16_x86_64
cp37-cp37m-manylinux_2_15_x86_64
cp37-cp37m-manylinux_2_14_x86_64
cp37-cp37m-manylinux_2_13_x86_64
cp37-cp37m-manylinux_2_12_x86_64
cp37-cp37m-manylinux2010_x86_64
cp37-cp37m-manylinux_2_11_x86_64
cp37-cp37m-manylinux_2_10_x86_64
cp37-cp37m-manylinux_2_9_x86_64
cp37-cp37m-manylinux_2_8_x86_64
cp37-cp37m-manylinux_2_7_x86_64
cp37-cp37m-manylinux_2_6_x86_64
cp37-cp37m-manylinux_2_5_x86_64
cp37-cp37m-manylinux1_x86_64
cp37-cp37m-linux_x86_64
cp37-abi3-manylinux_2_27_x86_64
...

In python 3.9.9, as provided by the python.org macOS installer,

$ /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
Python 3.9.9 (v3.9.9:ccb0e6a345, Nov 15 2021, 13:29:20) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.mac_ver()
('10.16', ('', '', ''), 'x86_64')

As a result, packaging 21.3 (and packaging main HEAD) do not include ...11_0... in packaging.tags.sys_tags(). However, wheel happily builds wheels with this tag, which pip (e.g. latest, 21.3.1) then refuses to install.

As platform.mac_ver() cannot be retroactively changed for released versions of Python, this should be addressed in packaging to make the support for macOS 11.x from #319 more robust.

Reference: https://trac.sagemath.org/ticket/33155

The switch to flit in #352 has left the packaging source tarball without a setup.py. While one can use flit install to install packaging, the flit install command provides a means to choose between installing to the system site-packages (possibly in a virtualenv, by providing a custom path to the python executable) or to a per-user site-packages.

Void Linux xbps-src, Arch Build System and Alpine apk-tools package builders all expect to install Python packages into a specific destination directory that is empty except for the contents of the Python package; the distribution package is derived from the contents of this directory. For setuptools-based projects like packaging<20.5, this is accomplished by passing, e.g., --root $DESTDIR for Void Linux. flit install provides no similar mechanism. The closest one could come would be to construct a virtualenv at the $DESTDIR, then use flit install to populate, and then carefully remove all pieces of the virtualenv from $DESTDIR except for the installed package. It should be self evident that this is a horrible workaround.

If you are use flit build and flit publish to build wheels and source tarballs on PyPI, this problem should take care of itself, because both flit subcommands appear to create a setup.py in the source tarball by default. (Note, however, that the generated setup.py appears incorrect because it imports distutils.core.setup, then uses the install_requires and python_requires keywords that seem to be only recognized by setuptools.setup.) However, the PyPI source tarballs for packaging==20.5, packaging==20.6 and packaging==20.7 do not include setup.py. Thus, you are either creating a source tarball by some other means, or invoking flit build --no-setup-py or flit publish --no-setup-py.

Without a setup.py in the source tarball (either generated by flit build or flit publish, or manually created to parallel the package definition in pyproject.toml), new versions of packaging cannot be properly packaged for Void, Arch, Alpine and, I imagine, several other Linux distributions.

PR #407 dropped LegacyVersion, but at the same time it broke the API of packaging.version.parse in a way that makes it very hard to support parse from both packaging 21 and 22.

In 21 if one called parse("...") it would return LegacyVersion instead of raising an error. So if code wanted to use parse but check that the version was correct it has to check whether the returned type was LegacyVersion.

In 22, LegacyVersion is now gone, and an exception is raised instead.

The deprecations raised for LegacyVersion were only raised when a LegacyVersion was created, so code that called parse and checked the return type didn't raise any warnings.

There is a problem building and using wheels for python 3.10 xref pypa/wheel#354 and pypa/pip#8312. I think the source of the problem is that wheel's bdist_wheel calls tags.interpreter_version. But tags.interpreter_version seems to be producing 310, which it will take from sysconfig.get_config_var("py_version_nodot") (if it exists), and there is no check that is conformant with the 3_10 format.

Internally, packaging uses tags._version_nodot which will always produce 3_10, this is the "correct" value used by pip and in tags.sys_tags.

This is the code that generates that value for CPython master. Note there is no '_'

I finally got fed up of writing the same code to parse wheel and sdist filenames, so I thought it might be worth having a "standard" version.

As written, the code only handles sdist filenames in the form described in the packaging standards (.tar.gz files with the form {name}-{version}.tar.gz). It could be extended to handle more of the cases in use on PyPI (e.g., .zip format sdists) but I chose in the first instance to stick with the stricter definition that's the current de facto standard.

Given the example, Requirement('enlighten >= 1.10.2') The string output of this is 'enlighten>=1.10.2' rather than 'enlighten >= 1.10.2'

I believe the lack of spaces between the specifier operators and versions as well as the requirement components reduces readability.

While the lack of spaces could be considered a stylistic choice, there's no option to modify it without additional code and it's inconsistent with the examples in PEP 440 and PEP 508. And while this isn't Python code, it's not consistent with the recommendation in PEP 8 that binary operators are surrounded by single spaces.

On some platforms, sysconfig.get_platform() returns a value with a space in it (e.g. isilon onefs). This causes problems for wheel building/handling.

First, there is an issue trying to build a platform-specific wheel:

# venv/bin/pip install -I --no-cache pyyaml
Collecting pyyaml
  Downloading PyYAML-6.0.tar.gz (124 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 125.0/125.0 KB 13.3 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: pyyaml
  Building wheel for pyyaml (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for pyyaml (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [101 lines of output]
...
      wheel.cli.WheelError: Bad wheel filename 'PyYAML-6.0-cp38-cp38-isilon onefs_9_5_0_0_amd64.whl'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for pyyaml

I created https://github.com/pypa/wheel/pull/491 to address this.

Even with that patch in place, though, pip is unable to install the built wheel because packaging does not recognize that the platform name has had its spaces replaced with underscores:

# python3 -m pip install dist/PyYAML-6.0-cp38-cp38-isilon_onefs_9_5_0_0_amd64.whl
...
ERROR: PyYAML-6.0-cp38-cp38-isilon_onefs_9_5_0_0_amd64.whl is not a supported wheel on this platform.

As prototyped in #646, I believe this repo is a nice place to house a general parsing and validation function for the PEP 621 [project] table in the pyproject.toml.

This returns a list of (build tool independent) validation errors and a TypedDict of the project data.

Heya,

This module takes a pyproject.toml dict (pre-parsed by a TOML library) and parses/validates the [project] table, according to PEP 621.

I feel this could be generically useful, for packaging tools?

If you agree, I can clean up the code a bit and add more tests, etc

In packaging 21.3 having a wildcard in the install_requires section of a setup.py worked fine. Example:

setup(
...
    install_requires=["hwtypes>=1.0.*"],
...
)

In version 22.0 it throws this error:

  File "/aha/lib/python3.8/site-packages/packaging/requirements.py", line 35, in __init__

    parsed = parse_requirement(requirement_string)

  File "/aha/lib/python3.8/site-packages/packaging/_parser.py", line 64, in parse_requirement

    return _parse_requirement(Tokenizer(source, rules=DEFAULT_RULES))

  File "/aha/lib/python3.8/site-packages/packaging/_parser.py", line 82, in _parse_requirement

    url, specifier, marker = _parse_requirement_details(tokenizer)

  File "/aha/lib/python3.8/site-packages/packaging/_parser.py", line 122, in _parse_requirement_details

    marker = _parse_requirement_marker(

  File "/aha/lib/python3.8/site-packages/packaging/_parser.py", line 143, in _parse_requirement_marker

    tokenizer.raise_syntax_error(

  File "/aha/lib/python3.8/site-packages/packaging/_tokenizer.py", line 161, in raise_syntax_error

    raise ParserSyntaxError(

packaging._tokenizer.ParserSyntaxError: Expected end or semicolon (after version specifier)

    hwtypes>=1.0.*

           ~~~~~^