4 ms·

> 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 depe

> 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).

joshuamorton 8y ago
At least with most packages this can't happen anymore. If a package owner distributes a wheel, you're good. Most packages do now.
zbentley 8y ago
> 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.
- AlphaSite 8y ago
  I’ve always found thinks like LWJGL tricker than pyglet etc.
  - profalseidol 8y ago
    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 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.
toyg 8y ago
> 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.
lmm 8y ago
> 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.

joshuamorton 8y ago

At least with most packages this can't happen anymore. If a package owner distributes a wheel, you're good. Most packages do now.

zbentley 8y ago

> 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.

AlphaSite 8y ago
I’ve always found thinks like LWJGL tricker than pyglet etc.
- profalseidol 8y ago
  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 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.

toyg 8y ago

> 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.

lmm 8y ago

> 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.