Hacker News Reader

Comment by crdoconnor | Hacker News Reader

setup.py doesn't give a consistent mechanism to specify those kinds of dependencies.

How so? Any package in setup.py can declare a install_requires listing, including version matchers, of its (direct) dependencies. Those dependencies themselves should take care of listing theirs and so on completing the chain so that tools like pip can do their job.

That doesn't mean you can't run into a situation where a dependency cannot be resolved, but I don't see any problems around specifying them.

How exactly is pillow supposed to specify in a standardized way that it depends upon libjpeg and that libjpeg-dev is supposed to be installed on debian based distros?

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.

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.

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.

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

Reply on news.ycombinator.com