Comment by mtalantikite | Hacker News Reader

Comment by mtalantikite | Hacker News Reader

Cargo from Rust and go fmt from golang have been some of my favorite things these past few years. Cargo isn’t perfect, as the author points out, but wow is it great to have it as a major part of the language’s ecosystem.

I recently got access to GPT-3 and was playing around with it, which meant breaking out Python for the first time in a while, and I just don’t understand how anyone deals with it. Poetry seems much better than what I remember Python ever having, but it’s not official of course and not everyone uses it. I somehow was hitting dependency issues with packages stuck in Python 2 and I couldn’t believe that’s still happening — it’s been over a decade now. Even ran into some very minor Black vs PEP 8 things. Somehow every time I touch Python I find myself fighting the tooling, which may just be my ignorance or bad luck.

Very thankful for Cargo and go fmt so I can just get on with things!

(And also the author is right, the Rust community is super welcoming. Thanks for that as well!)

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!

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?

Python packaging tooling and infrastructure is exactly like this: 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.

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

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.

Reply on news.ycombinator.com