Update package metadata

[ofek]

Background

Hello there! The Python packaging ecosystem has standardized on the interface for build backends (PEP 517/PEP 660) and the format for metadata declaration (PEP 621/PEP 631). As a result, the use of setup.py files is now heavily discouraged.

So, I'm spending my free time updating important projects so that they are modernized and set an example for others 😄

Summary of changes

This implements PEP 621, obviating the need for setup.py, setup.cfg, and MANIFEST.in. Support has not landed in setuptools, so builds will now use hatchling. It is quite stable and actively maintained, the only reason the version is 0.x is because 1.0.0 will drop support for Python 2. It's also on the major distribution channels such as Debian, Fedora, conda-forge, Nixpkgs, etc.

Other projects have done this such as pipx, tox, all Datadog Agent integrations, etc.

Notes

• This fixes the .gitignore file to ignore the actual executables, the current pattern in fact matches src/python/ensureconda/
• This documents support for Python 3.10, matching the CI test matrix
• This also drops support for EOL Python 3.6 since hatchling and other build backends like setuptools have already done so. This will not break anything because pip only looks for version candidates that satisfy the requires-python field. Here are stats for the curious: https://pypistats.org/packages/ensureconda
• The Git version is now shipped, removing the need for pkg_resources and thus reducing import/load time by ~400ms for me locally
• The source distributions on PyPI are erroneously shipping a build artifact *.egg-info from python setup.py develop; this is now fixed:
  

[jezdez]

@ofek While I appreciate your intentions here, it's worth waiting on setuptools since it's probably more likely to be maintained long-term than a single-author project hatch/hatchling.

I would suggest to wait for the implementation of PEP 621/631 in setuptools (which apparently is very close).

[ofek]

@jezdez Hello again!

I understand that critique but it's worth noting that setuptools is also mostly maintained by just one person. Additionally, it's an order of magnitude larger (making it less auditable and more prone to bugs), based on a deprecated standard library module that it now vendors, requires the presence of an additional package wheel to actually build wheels, and does not yet support the PEP 660 editable installation standard (related to the packaging error in the above screenshot).

Would you be open to a different build backend then? Some more info here: https://peps.python.org/pep-0517/#abstract

BTW that feature you linked will be experimental for some time.

[ofek]

Oh another benefit that encouraged python-tuf (which will soon be used by PyPI itself for PEP 458) to switch is that artifacts are reproducible 😄

[ofek]

@jezdez Sorry for not following up! I was out for a bit with bronchitis.

Do you want me to do anything else here?

[ofek]

Small update: Hatch will likely be adopted by PyPA in the next week

• https://mail.python.org/archives/list/[email protected]/thread/J2BL5XTTOCXUCELUE7L5P5HHJ7NXZGZ5/
• https://mail.python.org/archives/list/[email protected]/thread/ZWSSNKQJ3GRIAK73FJS6KHOJNUJZYOVX/

Nothing major will change, just the repo location

[jezdez]

Small update: Hatch will likely be adopted by PyPA in the next week

• https://mail.python.org/archives/list/[email protected]/thread/J2BL5XTTOCXUCELUE7L5P5HHJ7NXZGZ5/
• https://mail.python.org/archives/list/[email protected]/thread/ZWSSNKQJ3GRIAK73FJS6KHOJNUJZYOVX/

Nothing major will change, just the repo location

This is indeed good news, thanks for making the move!

[ofek]

Transfer complete! https://github.com/pypa/hatch