Lnaden
commented
2 years ago Thanks for opening the discussion here! You raise a number of good issues here.
we should get away from versioneer and setup.py.
I agree mostly with this notion. Versioneer has been such a great tool for forcing semantic versioning that finding replacements that are not a dependency in of themselves has been a slow process.
As for setup.py, this has been such a main stay of Python for so long, I don't think too many people are aware that other options exist. pip install and python setup.py are so ubiquitous with "install python package" that we'll need to be careful about pulling people away from them.
I think the final commit (PEP 621) can wait for next year, when there is hopefully more support in setuptools and other packaging tools.
Setuptools has been the larger reason I haven't pushed for this yet. setuptools.setup is the main workhorse of most python packages I know of for install purposes. They only started supporting pyptoject.toml in 61.0.0, and they also say that "For the time being, pip still might require a setup.py file to support editable installs." on their site https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html. As of this writing, version 61.0.0 has only been out for 4 months. I've wanted to give people a bit more time to update their systems before pushing people towards pyproject.toml.
That said, what better way to push for it than updating the cookiecutter? Its probably a safe time to start working on it, but this will also have to come with migration docs, or at least pointers to them. We'll also want to push for helpful errors to steer people off setup.py to the pyproject.toml.
eirrgang
mikemhenry
With distutils deprecated and slated for removal as early as Python 3.12, we should get away from versioneer and setup.py.
We should also try to be more consistent with documents like https://packaging.python.org/en/latest/tutorials/packaging-projects/ so that users and workshop participants find consistent information when they search around online. (https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/ is a bit behind https://setuptools.pypa.io/en/latest/userguide/index.html, to which it defers, and doesn't really include any pypi-specific info not already in the above-linked tutorial.)
https://github.com/eirrgang/cookiecutter-cms/tree/mei-pyproject-toml illustrates possible updates to the cookiecutter template.
I think the final commit (PEP 621) can wait for next year, when there is hopefully more support in setuptools and other packaging tools.
The first three commits could go in as a single PR, or could be broken up. First, I establish basic usage of pyproject.toml. I remove setup.py entirely in the third commit with a migration from versioneer to versioningit.
I think my usage of versioningit is consistent with the previous usage of versioneer. There are some possible alterations, though. For instance, if we don't want _version.py to be written in the source directory, we can opt not to use the write feature, but this may complicate editable installs and/or sdist builds.