Skip to content
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

Removing the legacy resolver #10946

Open
pradyunsg opened this issue Mar 7, 2022 · 6 comments
Open

Removing the legacy resolver #10946

pradyunsg opened this issue Mar 7, 2022 · 6 comments
Labels
type: maintenance Related to Development and Maintenance Processes

Comments

@pradyunsg
Copy link
Member

This is an issue to coordinate the discussion around removing the legacy resolver, and what all we need to do to make that possible.

@pradyunsg pradyunsg added this to the Drop the legacy resolver milestone Mar 7, 2022
@pradyunsg
Copy link
Member Author

There's a milestone for this, and #9644 is the only issue that's on there as "we should solve this before we remove the resolver".

Is there anything else we think we need to do, before removing the legacy resolver?

@pfmoore
Copy link
Member

pfmoore commented Mar 7, 2022

IMO, publicity. Yes, anyone using the legacy resolver via --use-deprecated should know already that they can't continue using it forever, but we'll inevitably get complaints from people who made that change and then forgot to follow up. It's way too easy to apply the quick fix, and then have the best of intentions to fix the root problem, but never get round to it.

Let's do a round of announcements in whatever channels we can find, giving a date when we're going to drop the old resolver. We can make it 100% clear that these are "you've already been warned, this is your last warning" announcements, and make it clear that we're not open to requests for further delays, but I do think we should be explicit.

@graingert
Copy link
Contributor

I use the legacy resolver to work around hash checking mode with constraints files: #9243

@pradyunsg
Copy link
Member Author

Ok, so now we have a tracking milestone for removing the legacy resolver.

This is basically ripe for someone to pick this up and drive -- this needs a bunch of communcation about this and some implementation work to resolve the outstanding issues in the milestone + removing the legacy resolver.

@ssbarnea
Copy link
Contributor

ssbarnea commented Oct 7, 2022

To be honest I would love to see dropping of the old resolved made a priority. The old one is so problematic that it does waste everyone's time. I will celebrate the days we bury it for good.

pip-tools folks want to deprecate and remove the support for legacy resolved, with makes the pip-tools codebase quite complex. Still, we need a target date for removal, one to include it in the deprecation message for anyone that would use the legacy code.

If pip folks can produce a date, it would be awesome as we can sync these changes. I am personally for 2023-01-01, but some might see it too aggressive.

@pradyunsg
Copy link
Member Author

pradyunsg commented Oct 7, 2022

Help making progress on https://github.com/pypa/pip/milestone/47 would be welcome. The transitory round of resolver work was done by a grant-funded >2FTE work over months. My guesstimate is that it'll be roughly half of that effort to fix the remaining issues (see the milestone) and kill the legacy resolver (see discussion above), on the order of weeks.

I don't think we can commit to a date until we know how long it would take to fix the aforementioned issues and what the availability of volunteers would be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: maintenance Related to Development and Maintenance Processes
Projects
None yet
Development

No branches or pull requests

4 participants