3 ms·
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
by Kwpolska 3y ago
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.
- xapata 3y agoI 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.
- eviks 3y agovenv and docker are exactly the indicators of how Python is bad
- globular-toast 3y agoAre screws bad because you need a screwdriver?
- eviks 3y agoYou're mistaking hammer for a screwdriver
- IshKebab 3y agoThat'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.
- xapata 3y agoI'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.
- globular-toast 3y agoNo, but you have to use Rust, Go or Deno.
- IshKebab 3y agoI 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.
- globular-toast 3y agoThe 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 :)
- delfinom 3y agoWell, 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.
- ecshafer 3y agoJava and ruby are similar ages as python and dependencies are much better stories there.
- fbdab103 3y agoRuby never had nearly the FFI/other language problem as Python so could almost entirely focus on Ruby-code delivery.
- cesarb 3y agoThe 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.
- pjmlp 3y agoMaven and Gradle support building C and C++ libraries just fine.
- IshKebab 3y agoWhile 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!