-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolving Home Assistant takes 12 hours with new resolver #10788
Comments
I can not reproduce, I get I tested on Ubuntu 20.04.3 LTS and changed the commands a little bit so they could be easily repeated without causing the state of the environment to change:
The
|
Thanks for filing this @balloob! ^>^ While I haven't started using Home Assistant yet, it's been on my radar and I appreciate the work that you and other volunteers who have worked on it, have put into it! Much like @notatallshaw, I'm unable to reproduce this with pip 21.3.1 on MacOS, with a The error is that exact same as @notatallshaw, as far as I can tell.
You are likely getting a warning from the legacy resolver about dependency conflicts as well -- it just does not fail when it encounters a dependency conflict. |
I experimented to see if I could "fix" the Here are two cases I found which seemed unresolvable:
I continued loosening requirements but unfortunately this eventually led to very long backtracking times. I used an experimental version of Pip I have which implements backjumping to try and speed up these very complex scenarios and continued trying to loosen the requirements. Eventually I was able to find a set of requirements that didn't conflict (minus the two packages above), and after switching to Python 3.9 to build them (I could not get Pip Freeze Output
|
Actually I rebuilt the requirements files with the above freeze information. Using these and fixing/removing the constraints file you can install using pip 21.3.1. Though you will need to figure out which libraries are too old for your requirements and look at why they have conflicts by updating them and see what the conflicts are. Here is a diff on the
And the diff on
|
Thanks for digging in! Is there a place where we can find your experimental pip version? We definitely have some old packages around for integrations that haven't been touched in years. Sometimes integration requirements get disabled when we raise our minimum Python version. Looks like we'll have to do so here too. It's too bad that our lax handling of dependencies of our integrations is finally catching up on us. It means we'll need to pro-actively take care of it. Ccurrently we do it once an issue is raised that something doesn't work. The requirements diff doesn't look too bad although I would hate to have to downgrade things (because it means we can't move forward!) |
You can If those packages are using poetry or using something like |
Yes but it's not stable so I don't guarantee anything about it. To explain a little bit about what it's doing, a backtracking optimization landed on pip 21.3: #10479 . This optimization is very good at handling the cases where the solution seems "obvious", i.e. A and B don't agree on what version C should be used, so it checks different versions of A and B until they do. However it's not very good at situations where you add a dependency A and it conflicts with multiple preexisting dependencies e.g. X, Y, and Z. In the experimental version I am testing I use backjumping in an attempt to make those scenarios more solvable. But it still has many limitations and my implementation at the moment is very hacky and I've not verified it other than testing it in complex scenarios and seeing how it performs. Here's a tag of the version I used to help here: https://github.com/notatallshaw/pip/tree/homeassistant . I think you can install it like so: It also only helps to a certain extent, allowing to make some of your requirements a little bit more flexible. You can't for example remove every version requirement from the hundreds of requirements and expect it to find a solution, I still had to very manually and iteratively loosen up the requirements. You might want to check how other large projects like
What makes it tricky to find the conflicting packages here is that everything is added at once. I wonder if it's possible you can break your integrations down in to logical sub groups and split your requirements in to those groups? Then at least you can test the issues in the groups and then once resolved see if you can install the groups together.
Python is a tricky language to manage such a large number of requirements. I wonder if you'll have to ultimately take some sort of vendoring approach so you can have different dependencies have different versions of their dependencies.
Yeah most of them look fine, but there's a few like |
We had the same problem with our CMS Plone which has lots of dependencies. With current pip main branch and this #10574 PR merged these issues are solved. Did you try it already? |
This is different, since they have dependency conflicts in the graph, rather than a dense graph post-resolve. |
FWI we in apache-airflow don't handle this very well either, other than carefully (and somewhat blindly) altering our deps when we run into a backtracking issue. |
In the past we used our constraints file to "solve" conflicts. That is similar to what is requested in pypa/pipenv#4530 to work with the new resolver. Having that feature means we can move fast again with shipping security updates when needed without having to rush to ship a security fix and update X other packages that cause backtracking issues. |
Yep - we have very sophisticated mechanism of both preparing and using constraints. In fact we are publishing a set of constraints for our users so that they can install airflow reliably. For example this is the only "official" way you can install 3.6 version of Airlfow 2.2.3 (from https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html)
The problem here is that it backtracked when we tried to upgrade the constraints. We have > 500 dependencies, so we do not upgrade constraints manually - we automated it. In our CI, the constraints will be automatically upgraded in the main build and whenever dependencies change. We are using So in our case the backtracking happens (sometimes) when we attempt to generate new constraints with BTW. It's pretty sophisticated mechanism with Airflow's >500 deps - I gave recently presentation on that where you can see most of the why's and how's if you are interested: https://www.youtube.com/watch?v=_SjMdQLP30s&t=2549s |
wow, that's still long pipenv's at least this way, you can cache the resolution step |
This only helps if you know a working set of dependencies to start with. The original set of requirements linked here didn't have a resolvable set of dependencies. |
@balloob Are things better now, with the current release of pip? |
We're still using the legacy resolver. We do have a GitHub Action in place to make sure we don't introduce new conflicts. However, we have no idea how we're going to handle upgrading components in the future once the legacy resolver is gone without being able to force a resolution (there was some recent discussion about this here As reported above, the resolving can be done in 15 minutes. So I guess this issue resolved 🥲 |
Description
The new resolver introduced in pip takes 12 hours to resolve Home Assistant, making it unusable for Home Assistant. Our current workaround is using the legacy resolver.
(Time measured on AMD Ryzen 7, 32GB memory)
The legacy resolver is going to be removed in #9631 making pip unusable for Home Assistant.
Home Assistant focuses on privacy and local control and is world’s largest open source home automation platform. In 2020 it was the 2nd most active Python project on GitHub (per State of the Octoverse 2020). We integrate over 1000 different APIs and each API is integrated via a Python package installed via pip (requirements.txt).
All our dependency versions are pinned, but the libraries that we use don’t pin their dependencies. This leads to long resolving time as the new resolver will download all the different potentially compatible versions to find the right one. Libraries don’t pin their dependencies because a library tries to be compatible with as many other projects as possible (we always make sure we don’t rely on HA specific API implementations).
I understand you don’t want to keep the legacy resolver around forever, but we would like to see that the new resolver is usable prior to it’s removal.
Expected behavior
Done in less than 15 minutes.
pip version
21.3.1
Python version
3.10
OS
Debian 11
How to Reproduce
Output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: