If package maintainer does not specify dependencies, what can be done, really?
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.
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.
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.
* 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).
0.02$ from a noob.
I've never run into a package that I needed to install which both A) had mandatory dependencies and B) refused to specify them in a way automated tools would understand and resolve. I'm sure there are packages out there which have this problem, because a dependency list is not mandatory in setup.py, but I've not had the experience of encountering such a package and I've been using Python for a living for over a decade now.