Due to the iterative nature of resolvelib I don't think can be implemented without the involvement of the provider, and I've not thought about what that API would look like yet, but at the moment the pattern is:
Breadth-first search of top level requirements
Depth-first search of everything else
The idea would be to change it to:
Breadth-first search of top level requirements
If all previous level requirements were pinned (or has only 1 possible version to choose), breadth-first search of the next level
Repeat step 2 until not true
Depth-first search of everything else
There are three common use cases I think this should speed up:
User pins one high level requirement, e.g. apache-airflow[all]==2.7.3, this would breadth-first search one extra level
User pins their own package (my-private-package==1.0), and that package pins all their direct dependencies (dependencies = ['PyYAML==6.0.1', 'requests==2.31.0']), this would breadth-first search two extra levels
User pins their own package (my-private-package==1.0), and provides constraints (-c locked-transitive-dependencies.txt) for all their dependencies and transaitive dependencies, this would breadth-first search all levels
Due to the iterative nature of resolvelib I don't think can be implemented without the involvement of the provider, and I've not thought about what that API would look like yet, but at the moment the pattern is:
The idea would be to change it to:
There are three common use cases I think this should speed up:
apache-airflow[all]==2.7.3, this would breadth-first search one extra levelmy-private-package==1.0), and that package pins all their direct dependencies (dependencies = ['PyYAML==6.0.1', 'requests==2.31.0']), this would breadth-first search two extra levelsmy-private-package==1.0), and provides constraints (-c locked-transitive-dependencies.txt) for all their dependencies and transaitive dependencies, this would breadth-first search all levels