3 ms·

It's not your imagination. Python tooling is awful. If I may be forgiven a bit of preaching, I'll point out that the fundamental problem with the Python ecosys

by cwp 6y ago

It's not your imagination. Python tooling is awful. If I may be forgiven a bit of preaching, I'll point out that the fundamental problem with the Python ecosystem is that package definitions are executable python code. This means they have their own dependencies, and are subject to all the pitfalls of general purpose programs - the halting problem, non-determinism etc. The Python community keeps trying to fix this by writing a better installer, and it's never going to work. NPM and Cargo, with their declarative package definitions, are built on a far more stable base!

rectang 6y ago
Whatever Perl's other issues, through the introduction of `META.json` CPAN successfully augmented a system designed for executable install scripts like `Makefile.PL` with a declarative package metadata mechanism. Why can't Python do the same?
dralley 6y ago
Python packaging tooling and infrastructure is exactly like this: https://xkcd.com/2347/ https://xkcd.com/2347/ Everybody uses it, but the work of maintaining it is thankless and doesn't receive nearly as much attention as you would expect relative to the popularity of the language. The unfortunate thing is that there's only a very small number of people actively maintaining, and they have so little time available that it's nearly impossible even to contribute something substantial. I bore witness to an attempt by my colleagues to replace the legacy XML-RPC APIs (which have been publicly declared as deprecated for years with no replacement even today) which completely fell through because the maintainers didn't want to (or have time to) provide any feedback whatsoever. It was basically requested that a 100% implementation with 100% test coverage be provided before they would even spend the time to evaluate the API design concept and give feedback.
neolog 6y ago
http://python-poetry.org/ http://python-poetry.org/ solves the problem by providing declarative package definitions.
rst 6y ago
Not sure I agree with this diagnosis -- Ruby gemspecs (for components) and Gemfiles (for dependency lists) are both executable Ruby code, but packaging troubles at the Pythonesque level are rare. The trouble I've had with Python packaging had a lot less to do with the specs being executable code than with there being tools with overlapping use cases which interpret them in different ways, none of which seems to cover all use cases, and whose documentation of what they expect in package specs is sometimes in conflict. If the specs turned to JSON-with-comments tomorrow, those problems wouldn't go away.

by cwp 6y ago

rectang 6y ago

Whatever Perl's other issues, through the introduction of `META.json` CPAN successfully augmented a system designed for executable install scripts like `Makefile.PL` with a declarative package metadata mechanism. Why can't Python do the same?

dralley 6y ago

Python packaging tooling and infrastructure is exactly like this: https://xkcd.com/2347/ https://xkcd.com/2347/ Everybody uses it, but the work of maintaining it is thankless and doesn't receive nearly as much attention as you would expect relative to the popularity of the language. The unfortunate thing is that there's only a very small number of people actively maintaining, and they have so little time available that it's nearly impossible even to contribute something substantial. I bore witness to an attempt by my colleagues to replace the legacy XML-RPC APIs (which have been publicly declared as deprecated for years with no replacement even today) which completely fell through because the maintainers didn't want to (or have time to) provide any feedback whatsoever. It was basically requested that a 100% implementation with 100% test coverage be provided before they would even spend the time to evaluate the API design concept and give feedback.

neolog 6y ago

http://python-poetry.org/ http://python-poetry.org/ solves the problem by providing declarative package definitions.

rst 6y ago

Not sure I agree with this diagnosis -- Ruby gemspecs (for components) and Gemfiles (for dependency lists) are both executable Ruby code, but packaging troubles at the Pythonesque level are rare. The trouble I've had with Python packaging had a lot less to do with the specs being executable code than with there being tools with overlapping use cases which interpret them in different ways, none of which seems to cover all use cases, and whose documentation of what they expect in package specs is sometimes in conflict. If the specs turned to JSON-with-comments tomorrow, those problems wouldn't go away.