Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> This was not by accident - Guido and others have always had the utmost care for good developer experience out of the box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now?

The Java module experience is miles ahead of the Python one. There's no global module path where you can install different things on different machines, nothing that screws up if you accidentally run it as root, no stateful virtualenvs where different shell windows run the same project with different versions of python. You just list your dependencies in your POM (which, yes, is XML; it was the early 2000s, everyone was doing it, and it does make it easy for your IDE to put a nice editor interface on it) and that's it, you're done: released versions are immutable and transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that. There's a well-known repository that all the important libraries are in; as and when you want to have a company private repository there are a couple of standard ones you can pick from and run, either just for your own artifacts or proxying third-party libraries from the central one as well. It all Just Works.

Maven came out 14 years ago and Python still doesn't have anything that works nearly as well.

> and that's it, you're done

You are seriously comparing Maven, a huge and over-complicated xml-based system that is not even installed by default and that people hate so much that there are umpteen alternatives (gradle etc), with `pip install -r requirements.txt` that works out of the box? I just can't even...

> Python still doesn't have anything [like Maven]

And I thank the Gods for that.

> a huge and over-complicated xml-based system

It's not complicated. It's verbose, that's the nature of XML, but the behaviour is very direct.

> is not even installed by default

Which is the better approach because it means it's not coupled to specific versions of the language itself. You can use a single maven install to manage multiple versions of Java (or vice versa); if you need to rely on a new maven feature in a project that's stuck on an old version of Java, it's no problem.

> people hate so much that there are umpteen alternatives (gradle etc)

There will always be refuseniks (particularly for pioneers; most of the things people hated maven for are the same things people love cargo et al for) but the Java ecosystem has done a very good job of keeping everything interoperable; it doesn't matter if one of the libraries I call builds with gradle, because there's a common packaging/dependency/repository standard, so everything will just work exactly as it should.

> with `pip install -r requirements.txt` that works out of the box?

Until you come to upgrade, or until you run it the wrong way (e.g. forgetting to start your virtualenv first) and mess up your system install.

> with `pip install -r requirements.txt` that works out of the box?

Works out of the box until you're missing a distro package that is required to build a dependency that needs to be compiled from source.

I've never used maven so I don't know if it is better or worse, but I am not a fan of languages having their own package management system that has not integration with the distro one (which probably also offers some of the same packages, and mixing them breaks things in subtle, annoying ways).

> Works out of the box until you're missing a distro package that is required to build a dependency

With decently-maintained packages on PyPI, i.e. shipping prebuilt wheels for the most common architectures, that's no longer a problem - unless you insist in using the distro package-manager, in which case you should pick it up with the distro people. If you stick to pip+venv, on most common architectures, these days chances are you only need a simple `install`.

> I am not a fan of languages having their own package management system that has not integration with the distro one

You must feel miserable then, considering it is pretty much all modern ones. Go, Rust, Node, Perl, Python, PHP, Java, even C# and friends...

There will always be tension between what developers want (the library released yesterday and can be forever tweaked) and what OS/sysadmins want (the library that has been tested for months and can be locked down). This is why platform-agnostic delivery systems for developers are so popular, and it is not going to change any time soon.

> I've never used maven so I don't know if it is better or worse, but I am not a fan of languages having their own package management system that has not integration with the distro one (which probably also offers some of the same packages, and mixing them breaks things in subtle, annoying ways).

Mixing is where Python (and Perl, even though it is integrated with the distro package management) go wrong, IME. Maven is isolated from the host package management but completely (or at least completely enough, in practice); most OSes don't bother trying to ship system-wide versions of Java libraries. The OS manages the JVM (and Maven), Maven manages whatever libraries an app wants on a per-app basis, and neither interferes with the other.

This does mean you get very little help managing dependencies of JVM libraries on native libraries; fortunately those are rare enough in the JVM ecosystem that you can handle the few that do occur by hand, IME.

> I've never used maven so I don't know if it is better or worse

It's about the same for packages with a native component. Local build tools are still needed.

Java stuff is slightly less likely to have a compiled component in the first place, in my entirely subjective impression. Maybe that's because of convention, or performance; I don't know. But when a compiled dependency does exist, and nobody included a prebuilt chunk of binary for your architecture in the jar, a build is needed in roughly an equivalent fashion to what pip (or npm, cpan(1), etc.) do.

I’ve always found thinks like LWJGL tricker than pyglet etc.

That's because LWJGL is complicated just like DirectX is. It uses low level API that calls native C code. It aims to give you a thin Java API layer above OpenGL, Vulcan, controllers, audio, etc.

https://en.wikipedia.org/wiki/Lightweight_Java_Game_Library

Whereas pyglet, seems to me like a high-level regular game engine that includes a widget library.

At least with most packages this can't happen anymore.

If a package owner distributes a wheel, you're good. Most packages do now.

I do not see your comment as fair to the parent:

> there are umpteen alternatives (gradle etc)

there was ant (build tool) then came maven which is much more flexible and contains dependency management capabilities (and _is loved_ by many) nothing to add that the parent did not already say. Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration.

pip did not ship with python for a long time, and has problems of its own.

> Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration

You make it sound like adding Apache Groovy for configuration to a build system is an improvement. When build systems with a declarative config language, such as make, ant, and maven, replace procedural build scripts, that's the improvement. Using a procedural language like Groovy instead is a large leap backwards because it encourages programmers to add unneeded procedural features to build scripts, creating an unmaintainable mess.

I agree, my above comment was aimed at this part of the parent comment:

> a huge and over-complicated xml-based system

It was an attempt to show that there are not 'umpteen different alternatives' and the ones that exist, do so for a reason. Though looking back, I should have worded it in a better way.

Pip was not part of Python by default for a long time.

Right.

A post on my blog:

pip now installed with Python 2.7.9:

https://jugad2.blogspot.com/2015/03/pip-now-installed-with-p...

which mentions:

https://docs.python.org/2.7//installing/index.html

and::

https://pip.pypa.io/en/latest/installing/#pip-included-with-...

I've used Python versions before that, where you had to install pip separately, and it was not trivial (to find it / install it), although not very difficult either.

There's a lot I don't like about Maven, but its a vastly better solution than pip. Support for dev dependencies and no need to manage virtual environments more than makes up for its complexity.

There's pipenv now, which wraps pip and venv to do all that in a super simple way.

It has some performance issues but it's still quite a recent project.

> transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that

Is that true? I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions. (Yarn and npm both generate a lock file automatically, pinning all dependency and subdependency versions, which seems great.) It seems like I could specify all of the subdependencies in my own pom.xml file too with specific versions, but maven doesn't appear to make that easy to do.

> I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions.

Version ranges are indeed nondeterministic, that's why they're discouraged by the community (and IME very rare).

Pinning specific ones is easy enough (I tend to just look at the dependency tree in eclipse and right click -> lock transitive dependency version); I can't find a way to do that for all transitive dependencies though (I've never had more than a handful of transitive dependencies that used ranges, so it's not been a problem I've had tbh).

Reply on news.ycombinator.com