Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Python packaging world is full of barely compatible tools and no clear vision. Even if you're consuming packages, or packaging pure Python code, it's often an incomprehensible mess.


Well, part of it is really Python's age and legacy. We are talking about going back to 1996. So much of python's development was ducktape through history in response to the changing world and whims of the contributors.

I'm not saying it's an excuse but it's just how it got to where it was. Newer languages have alot of lessons learnt to build upon to be decent from day 0.


Java and ruby are similar ages as python and dependencies are much better stories there.


Ruby never had nearly the FFI/other language problem as Python so could almost entirely focus on Ruby-code delivery.


The same for Java, since its ecosystem has an allergy to calling native (non-JVM) code, to the point of rewriting perfectly good libraries in Java. When they do call native code, it's often in horrible ways (like copying a native library from within the JAR file to a temporary directory, and loading it from there, the JAR file coming with pre-compiled native libraries for all possible operating system and architecture combinations). So the Java package managers mostly focus on Java (and other JVM languages) code building and delivery.


Maven and Gradle support building C and C++ libraries just fine.


While this may be true, they've also had literal decades to improve the situation and have barely got anywhere. In some ways they've gone backwards!


I haven't found it so. I've stuck with pip and adopted venv when it showed up, and haven't needed anything else. I use Docker for "pinned" builds.


venv and docker are exactly the indicators of how Python is bad


Are screws bad because you need a screwdriver?


That's a completely nonsensical analogy. Maybe you missed his point, but well designed programming language infrastructure does not need Docker or venv to work. The fact that you have to resort to the massive hack of Docker shows how bad the situation is.

I do not have to use Docker or a venv for my Rust, Go or Deno builds.


I'm not a Rustacian, but so far I much prefer Python's packaging to Go's. Italicize all you like. I don't find the emphasis convincing.

When I receive a Python program that I'd like to modify, I can. When I receive a Go program that I'd like to modify, I must beg for the source code.

Do you "vendor" your database into your Go program? If not, you likely still need Docker, or something like it, for your program to work.


No, but you have to use Rust, Go or Deno.


I get to use Rust, Go or Deno (for my own projects). I am forced to use Python for work unfortunately.

It's not a terrible language for sure. It's just the packaging systems and tooling around it that are face-palmingly awful.


The thing is I've learnt Python packaging one time basically (obviously there's always more to learn about anything) and that's enabled me to write a ton more software than I would have written otherwise. For example, just a little plotting utility for me to visualise my accounting data. It's on GitHub, but nobody uses it but me. Could you imagine me writing this in anything but Python?

If your projects really do benefit from other languages, maybe you're doing network or systems applications that need to be fast, then you might have easier packaging but those languages require easy more work due to fewer libraries or just being harder (Rust).

As usual with these things it's six of one and half a dozen of the other :)


You're mistaking hammer for a screwdriver




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: