[throwaway894345]

I get that resolving dependencies is a SAT problem and inherently intensive; however, I don't understand why it's so much slower in Python. Is it just that all of these resolvers are implemented in Python (and Python is really that much slower than other languages?), or does Python require you to download an entire package just to determine its dependencies? In the latter case, that seems pretty dumb, right? Like as bad as exposing the entire interpreter as the extension interface, rendering optimizations and competing interpreters virtually impossible.

[raziel2p]

> does Python require you to download an entire package just to determine its dependencies?

yes - the standard way of defining dependencies in Python is in setup.py, which has to be invoked as a Python script in order to work. this script may also need to read files from the rest of the project, so you do indeed need to download the whole package to determine its dependencies.

even if the Python community were to agree on a new configuration format tomorrow, there would still be a ton of packages out there that wouldn't migrate for years.

[epistasis]

It seems that this information should cacheable after an invocation of setup.py, at least for an installation without any extras. And even with extras requested, perhaps.

Or is there any even greater hidden challenge from using setup.py?

[JaDogg]

setup.py can check the OS and pick necessary requirements. so it can have different dependencies in different OSes.

I've used it like this - https://github.com/JaDogg/pydoro/blob/b1b3de38ac15b9254ef1be...

[claytonjy]

Does this imply that poetry will "solve" dependencies quicker the more of the dependencies use `pyproject.toml`? Or is that "hidden" once something is sent to PyPI anyways?

[uranusjr]

With several asterisks attached, but yes, the move would make dependency resolution faster.

[darkarmani]

That's why conda stores the metadata in a repodata file. Solving dependencies happens first; then binary packages are downloaded.