Modernize packaging setup #50
Conversation
Whereas: * Running `setup.py` manually is deprecated: https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html * Current versions of Pip will not run `setup.py install` under normal circumstances; even when given an sdist, Pip will prefer to build a wheel and then install that normally: https://pip.pypa.io/en/stable/reference/build-system/setup-py/ * Pip does not make any guarantees of any special support for Setuptools-based projects going forward (same link); * The post-install hook simply attempts to migrate "new" config settings keys into the user's private config file; * At startup, the code *already* checks for the presence of that config file and generates it if missing; Therefore I conclude that this hook no longer has any value. Instead, the startup check is modified to add the missing keys when the file already exists.
This change allows the project to build compatible sdists and wheels following modern packaging standards. Declarative metadata is better for the ecosystem, as it allows tooling to learn about the package without having to build it first. (Of course, building is not normally required for this project anyway, since it distributes a wheel.) Using the new standards, everything can be done without any code in `setup.py` nor special instructions in `MANIFEST.in`.
|
Please note that support for |
These changes allow the project to go forward following modern packaging standards, entirely dropping dependency on running arbitrary code from
setup.py(which is normally not required for pure Python projects).Instead of trying to implement a post-install hook (which wouldn't ordinarily run nowadays anyway), the logic for updating old config files is pushed into the startup check for a missing config file.
Project metadata is specified using
pyproject.toml, following the standards described in:As a result, the sdist includes a
PKG-INFOmetadata file that could in principle be used by other tooling to read project metadata, without needing to build the project (from their perspective: slow and insecure).With these changes, using the new functionality, a separate
MANIFEST.infile is also no longer necessary. All project configuration is done declaratively, in one place.