No, the problem is that Python's packaging system (like Homebrew's!) was created without adequate reference to prior art, has undergone much more evolution than design, and has suffered in every attempt to improve it from the fact of its adoption by a large userbase which democratically manages it so that changes must be conservative.
As a result, Python packaging has an utterly insane design that it can't evolve its way out of.
Problems that have proven more or less intractable for resolution by evolutionary change:
- total lack of static metadata— you must download a source package and attempt to build it in order to determine what its actual dependencies are
- relatedly, package setup scripts are way too powerful and can do literally anything, which makes automating Python packaging a nightmare
- any possible vendorization is deeply limited by the fact that Python processes can't include multiple versions of a single library
- the behavior of all Python packaging tools relies on the implicit state of PyPI, forcing a high degree of non-determinism unless you go to great lengths to take snapshots of PyPI
- native dependencies (i.e., dependencies on C libraries) are either just totally undeclared, or packaged abuse setup.py in order to manually compile them in an ad-hoc, unmanaged fashion
There's no way out of this that doesn't involve breaking things for Python developers who are, whether out of shortsightedness or resigned pragmatism, relying on or working around the many, various bad practices that the Python packaging 'system' currently allows.
This is why programmatically generating Python packages for general-purpose package managers like Homebrew ranges (depending on the resources made available by the package manager's design) ranges from impossible to stupidly complex and computationally expensive to kinda works but has no hope of reliability/correctness/completeness.