Closed theunkn0wn1 closed 2 years ago
As you're the maintainer I’ll leave the decision on what to do up to you, but to chime in with some of my own experiences:
Personally I’ve found elaborate use of poetry and pyproject.toml to be mostly unwieldy solutions in search of a meaningful problem for my use cases, also applicable here since pydle has very few requirements.
For personal projects, I’ve switched to converting setup.py
to its declarative cousin, setup.cfg
, and a simple pyproject.toml
as follows:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
and an stub setup.py
as some setuptools
features won't work without it (especially in older versions):
# for legacy compatibility
from setuptools import setup
setup()
I think this generally provides a good balance, as tools like mypy
and yapf
also support being configured through setup.cfg
. I also generally opt to remove requirements.txt
and put the dependencies in extras_require
in setup.cfg
.
Hope this helps.
Thank you for your opinion @Shizmob .
Its currently a toss up between switching to setuptool's newer declarative interface with setup.cfg
+ pyproject.toml
, and using poetry
with pyproject.toml
.
Mypy, yapf, black, and pytest all support configuration via pyproject.toml, which appears to be the new standard.
requirements.txt
will be removed regardless of the choice made, as both paths move that configuration.
I am fine going either way.
In my personal projects, i find poetry is useful even when there are very little requirements, given its ability to also handle virtual environments and how painless packaging with it is.
I also recently used the newer setuptools format in a project, and found a footgun or two around package discovery leading to broken wheels.
The only real benefit of setuptools
today that i see is its support for native modules, which pydle thankfully doesn't deal with.
The build system hasn't been meaningfully touched in a very long time, and uses the old-style
setuptools
setup.Python has moved on from this, and Setuptools has a newer, cleaner interface that should be used instead based on PEP517.
Additionally, with the introduction of PEP-517, I have become partial to using poetry as a replacement for
setuptools
, and am interested in using that for Pydle's packaging solution instead.Regardless of which tool is used, Pydle should modernize.
I do no view the build system as covered by semver, and it will not break existing installs or block them from upgrading. Switching to PEP517 will only effect source installs that use an outdated pip. Installers from pypi should be unaffected.