[heartsucker]

I think the author meant packages output of pip, like this issue:

I want to install the pip package cryptography. I need to make sure Python.h is available. I need to make sure (on Debian) that lib-ffidev and lib-ssldev are available. This isn't said anywhere by pip (except Python.h, probably), and it's not the same on every system, let alone every Debian based system.

[daenney]

Ah, right, that makes sense. I don't think it's a fair criticism though, as you're crossing the boundaries between packages provided by your language ecosystem vs. those provided by your OS (distribution). There's no easy way to specify this in a way that would work on all platforms or you'd have to start adding logic to pip that knows how to apt/yum/pacman/port install those things.

It's the same if you look at Ruby, Node, even Go and many others. The second you need native libraries/binaries all you have to go on is the hope that the author has documented them along with the rest of the installation instructions. The current only way around it is hoping that your distribution has packaged up the library you need (and is up to date enough for your requirements) in their native format and declaring the required dependencies.

[crdoconnor]

There's two ways around this:

* Provide a way to detect the package or lack thereof and fail in a consistent, easy to understand way. This part actually wouldn't be too hard.

* Provide a way to use the package via nix, guix or pkgsrc instead and enforce its usage so the OS package manager stops mattering. This has the additional benefit that you can specify versions (fairly important since different versions of those dependencies can have far reaching effects).

[Eridrus]

It's entirely solved with binary packages if you look at Java. You can even get a whole headless webkit (ui4j) setup from 2 maven packages without having to ever touch apt.