3 ms·
With declarative tooling - unlike setup.py - we've lost the ability to install to locations not managed by Python. Most of my projects used to have a python-cod
by orbisvicis 2y ago
With declarative tooling - unlike setup.py - we've lost the ability to install to locations not managed by Python. Most of my projects used to have a python-code config file that I could include both in my code and in setup.py. Last I checked none of that is now possible. Want to install a system binary - ship an RPM or a flatpak.
I don't understand how we could lose so much flexibility and yet gain so little in return.
P.S I've only ever encountered minor dependency issues in my admittedly small projects using just pip and venv.
- OJFord 2y agoThat's entirely appropriate imo - system packager should be running pip or whatever and then putting the output where it wants, it's not for setuptools or whatever to declare that. What path would you put in setup.py anyway? A different one for different distro preferences, a different one again for Windows, for macOS?
- heavyset_go 2y agoYou can still use the setuptools backend when using declarative tooling, I use it in projects I can't fully port to pyproject.toml.