Open jgrey4296 opened 11 months ago
Hi @jgrey4296,
is there an issue with the current approach? What problem does this solve for an end-user?
Cheers Manuel
less an issue, just standardization. with 2.7 EOL, the additional dependencies and older build config were extra hurdles to getting to what I wanted: whitespace patterns. I ended up doing this shift at the same time as I was figuring out the project code. if you want to use it, cool, if not, cool.
https://setuptools.pypa.io/en/latest/userguide/quickstart.html#setuppy-discouraged https://setuptools.pypa.io/en/latest/userguide/quickstart.html
We recommend users expose as much as possible configuration in a more declarative way via the pyproject.toml or setup.cfg, and keep the
setup.py
minimal with only the dynamic parts (or even omit it completely if applicable).
From validate-pyproject
README:
With the approval of PEP 517 and PEP 518, the Python community shifted towards a strong focus on standardization for packaging software, which allows more freedom when choosing tools during development and make sure packages created using different technologies can interoperate without the need for custom installation procedures.
This shift became even more clear when PEP 621 was also approved, as a standardized way of specifying project metadata and dependencies.
validate-pyproject
was born in this context, with the mission of validatingpyproject.toml
files, and making sure they are compliant with the standards and PEPs.
https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#writing-pyproject-toml
This does an initial basic replacement of setup.py / setup.cfg to use pyproject.toml. As mentioned here, there was a block due to using lib3to6, but as python 2.x is end of life'd... i've just removed sub 3.6 dependencies. I also replaced the deprecated pkg_resources with packaging.version.parse.
This breaks a couple of CLI tests partly due to logging differences, which i'm not sure about.