Present found conflicts when trying to resolve them #10258

nadavwe · 2021-08-02T13:21:33Z

Resolves #9254

src/pip/_vendor/resolvelib/resolvers.py

nadavwe · 2021-08-02T13:34:40Z

src/pip/_internal/resolution/resolvelib/resolver.py

+                functools.partial(
+                    self.factory.get_backtracking_reason_message,
+                    constraints=collected.constraints,
+                )


this feels somewhat ugly to me, but passing the constraints and factory to the reporter felt weird as well.
would love to get your decision on that.

uranusjr · 2021-08-07T16:47:23Z

Hey, sorry for the delay, just want to say I still remember this and will eventually come back to review this (and the accompanying resolvelib PR). But I need to prioritise fixing 21.2.x over this (which targets 21.3 and beyond).

nadavwe · 2021-08-08T09:27:41Z

Hey, sorry for the delay, just want to say I still remember this and will eventually come back to review this (and the accompanying resolvelib PR). But I need to prioritise fixing 21.2.x over this (which targets 21.3 and beyond).

sure, np. :)

notatallshaw · 2021-08-29T18:26:24Z

Would it make sense to display this message every time the causes change during the backtracking? Not just when backtracking first starts.

E.g.

failure_causes = e.causes
if self._failure_causes != failure_causes:
    ... # log message
    self._failure_causes = failure_causes

Or am I missing something and this is way beyond the scope of the PR?

nadavwe · 2021-09-01T06:52:10Z

@notatallshaw do you have an example of where you did not get what you expected?

notatallshaw · 2021-09-01T12:47:41Z

@notatallshaw do you have an example of where you did not get what you expected?

Apologies, I think I misread the description of the PR and title. I'll try actually running the PR against a few examples I've built up on #10201 where it's not clear to the user why backtracking is happening.

notatallshaw · 2021-09-15T15:46:41Z

Thanks for your patience, I was trying to test this with the following real world use case ad I couldn't get it to trigger:

pytest-cov
coverage==4.5.4
boto3

Am I missing something?

nadavwe · 2021-09-29T07:43:16Z

Thanks for your patience, I was trying to test this with the following real world use case ad I couldn't get it to trigger:
pytest-cov
coverage==4.5.4
boto3
Am I missing something?

Hey, sorry for the long time.
not sure what does not work for you...
I got the following messages:

INFO: Cannot install coverage==4.5.4, coverage[toml]==5.2.1, coverage[toml]==5.3, coverage[toml]==5.3.1, coverage[toml]==5.4 and coverage[toml]==5.5 because these package versions have conflicting dependencies.
The conflict is caused by:
    The user requested coverage==4.5.4
    coverage[toml] 5.5 depends on coverage 5.5 (Installed)
    The user requested coverage==4.5.4
    coverage[toml] 5.4 depends on coverage 5.4 (from https://files.pythonhosted.org/packages/14/63/469e42ebb87f455528d3d317eb8b0299d48008eee3a043cd1be65b4efe9e/coverage-5.4-cp37-cp37m-macosx_10_9_x86_64.whl#sha256=1b811662ecf72eb2d08872731636aee6559cae21862c36f74703be727b45df90 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.3.1 depends on coverage 5.3.1 (from https://files.pythonhosted.org/packages/29/7c/890e84955a056af4296aa774624fdafbad5cb4b6eeabeeca9cd9f0b3494d/coverage-5.3.1-cp37-cp37m-macosx_10_9_x86_64.whl#sha256=fac3c432851038b3e6afe086f777732bcf7f6ebbfd90951fa04ee53db6d0bcdd (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.3 depends on coverage 5.3 (from https://files.pythonhosted.org/packages/a8/64/40654143f443c71c0eddbfe7a050bfffbfd2bb8bbd349941b6f5f5ceabc4/coverage-5.3-cp37-cp37m-macosx_10_13_x86_64.whl#sha256=e8caf961e1b1a945db76f1b5fa9c91498d15f545ac0ababbe575cfab185d3bd8 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.2.1 depends on coverage 5.2.1 (from https://files.pythonhosted.org/packages/fa/b1/a7dd5d8931ae8b2e3966af7bdf77b064f4e78d398db230fbf06e343d340b/coverage-5.2.1-cp37-cp37m-macosx_10_13_x86_64.whl#sha256=c890728a93fffd0407d7d37c1e6083ff3f9f211c83b4316fae3778417eab9811 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))

notatallshaw · 2021-09-29T13:16:35Z

Thanks for your patience, I was trying to test this with the following real world use case ad I couldn't get it to trigger:
pytest-cov
coverage==4.5.4
boto3
Am I missing something?

Hey, sorry for the long time. not sure what does not work for you... I got the following messages:

INFO: Cannot install coverage==4.5.4, coverage[toml]==5.2.1, coverage[toml]==5.3, coverage[toml]==5.3.1, coverage[toml]==5.4 and coverage[toml]==5.5 because these package versions have conflicting dependencies.
The conflict is caused by:
    The user requested coverage==4.5.4
    coverage[toml] 5.5 depends on coverage 5.5 (Installed)
    The user requested coverage==4.5.4
    coverage[toml] 5.4 depends on coverage 5.4 (from https://files.pythonhosted.org/packages/14/63/469e42ebb87f455528d3d317eb8b0299d48008eee3a043cd1be65b4efe9e/coverage-5.4-cp37-cp37m-macosx_10_9_x86_64.whl#sha256=1b811662ecf72eb2d08872731636aee6559cae21862c36f74703be727b45df90 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.3.1 depends on coverage 5.3.1 (from https://files.pythonhosted.org/packages/29/7c/890e84955a056af4296aa774624fdafbad5cb4b6eeabeeca9cd9f0b3494d/coverage-5.3.1-cp37-cp37m-macosx_10_9_x86_64.whl#sha256=fac3c432851038b3e6afe086f777732bcf7f6ebbfd90951fa04ee53db6d0bcdd (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.3 depends on coverage 5.3 (from https://files.pythonhosted.org/packages/a8/64/40654143f443c71c0eddbfe7a050bfffbfd2bb8bbd349941b6f5f5ceabc4/coverage-5.3-cp37-cp37m-macosx_10_13_x86_64.whl#sha256=e8caf961e1b1a945db76f1b5fa9c91498d15f545ac0ababbe575cfab185d3bd8 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))
    The user requested coverage==4.5.4
    coverage[toml] 5.2.1 depends on coverage 5.2.1 (from https://files.pythonhosted.org/packages/fa/b1/a7dd5d8931ae8b2e3966af7bdf77b064f4e78d398db230fbf06e343d340b/coverage-5.2.1-cp37-cp37m-macosx_10_13_x86_64.whl#sha256=c890728a93fffd0407d7d37c1e6083ff3f9f211c83b4316fae3778417eab9811 (from https://pypi.org/simple/coverage/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4))

Great! I must of tested it wrong somehow. I love this change, even with the performance improvements I'm hoping my PRs will bring to backtracking it will still be very useful to users to know why backtracking started.

uranusjr · 2021-10-25T03:02:58Z

src/pip/_internal/resolution/resolvelib/factory.py

@@ -47,6 +47,8 @@
 from pip._internal.utils.hashes import Hashes
 from pip._internal.utils.packaging import get_requirement
 from pip._internal.utils.virtualenv import running_under_virtualenv
+from pip._vendor.resolvelib.resolvers import RequirementInformation
+from pip._vendor.resolvelib.structs import RT, CT


Since they are from the .pyi file, these are not available at runtime and must be hidden inside if TYPE_CHECKING.

honestly I just added those so mypy won't fail... 😬
should I use them with the if TYPE_CHECKING or should I use a more generic type?

RT and CT are needed in resolvelib because it treats requirement and candidate classes are opaque types; those have concrete implementations in pip though, so you can just do

RequirementInformation[Requirement, Candidate]

but you still need to do some if TYPE_CHECKING dance since RequirementInformation is only a generic at type-checking level, not at runtime (another restriction with pyi files). I think there's an existing usage for that you can copy.

oh, right. I get it now.
resolvelib is completly unware of the types, but in pip we have concrete types.
thanks, that makes total sense.

and i think i found an example in the provider:

pip/src/pip/_internal/resolution/resolvelib/provider.py

Line 24 in 26eaddc

PreferenceInformation = RequirementInformation[Requirement, Candidate]

Yup, I think that's the one.

nadavwe · 2021-10-25T06:33:09Z

from running this a bit in the wild i see that resolving_conflicts is called multiple times.
I think I should only present the first time this method is called. WDYT?

uranusjr · 2021-10-25T06:35:09Z

Hard to tell, we probably need to sample some real examples to see which presentation works best from the user's perspective.

nadavwe · 2021-10-25T06:45:30Z

Hard to tell, we probably need to sample some real examples to see which presentation works best from the user's perspective.

I think i'll start with having this just once, and we can decide later to change this to some other logic.
from my limited usage it just feels that writing more than once creates some (i.e. a lot(!)) of logs. ^_^

uranusjr · 2021-10-25T08:16:11Z

news/10210.feature.rst

@@ -0,0 +1 @@
+found conflicts are output before pip delves into version resolution.


Suggested change

found conflicts are output before pip delves into version resolution.

Display found conflicts are before pip delves into version resolution.

(Not sure if I understand this message correctly. The point is to turn this into a complete sentence so the changelog reads better.)

nadavwe · 2021-10-25T09:16:27Z

@uranusjr I still want to change this to a single message, so let's wait and not merge yet.

Anyhow, thanks for your reviews and patience for a first-time contributor! :)

pradyunsg · 2021-10-26T06:22:36Z

If you’re looking for an interesting test case, try pip install pyrax==1.9.8. :)

nadavwe · 2021-11-08T11:43:23Z

@uranusjr I still want to change this to a single message, so let's wait and not merge yet.

Anyhow, thanks for your reviews and patience for a first-time contributor! :)

Hi @uranusjr,
I've made the change I wanted.
would be happy if you could review this for the last time and approve/merge.
thanks! :)

malthe · 2022-03-02T15:26:04Z

@pradyunsg are you able to bring this forward with this information?

I think there is consensus that "backtracking" needs to be noisy and that a summary at the end is useful. It also seems useful to put a hard limit on the number of versions to try – perhaps expressed as a total number of packages downloaded (regardless of whether a package was cached or not).

pfmoore · 2022-03-02T15:48:50Z

@malthe while there may be consensus on that, it's only really in the case where resolution fails (I've not re-read the threads to be sure, and personally I find that too much output in the "everything worked" case is annoying). I don't think there's been much consideration of how much of a problem the additional verbosity would be in simpler cases where everything works as expected.

I don't have any good answers - UX is hard - but the tricky part of discussions like this is that the participants are, of necessity, self-selected to be people hitting the problem cases where extra information is self-evidently useful... This makes it hard to get a good picture of the actual impact.

malthe · 2022-03-02T15:53:01Z

@pfmoore but is this really what a user wants – to download lots of software just to realize that versions are incompatible? I think there should be some noise in the output to let the user know that they're using software that isn't constrained properly.

pfmoore · 2022-03-02T16:00:59Z

As I said, if resolution is impossible then yes, knowing what's going on in that case is likely to be good. But users definitely want pip to try different versions in order to find a working installation (that's exactly why we implemented the new resolver). And if it manages to, then they probably want that to "just work" without pages of irrelevant (to them) messages. The problem is that we can't tell in advance whether the resolution will work or fail, so we can't decide up front whether to be quiet or noisy.

william-silversmith · 2022-03-02T16:10:29Z

The soon as backtracking starts going more than a few extra downloads, my users want to debug the conflict asap and have no tools to do that without waiting a long and indeterminate amount of time. On CI, a bad case can potentially exceed the running time allotment of the CI runner so no output is provided. I don't think users regard more than a small hiccup as anything other than a bug in installation.

malthe · 2022-03-02T17:10:06Z

@pfmoore seems to me that the correct solution to this problem is to allow pip to use an external service --resolver <url> which can efficiently resolve packages from a cache, e.g. --resolver https://resolver.pypi.org. Having each client attempt to do this brute-force isn't a good solution although it may work well in some (perhaps most) cases.

astrojuanlu · 2022-03-02T19:07:43Z

I think there is consensus that "backtracking" needs to be noisy and that a summary at the end is useful.

I don't agree that there's consensus in presenting a summary at the end. At least in my case I was advocating for presenting the conflicts right when the backtracking starts, see my earlier comment.

pfmoore · 2022-03-02T19:11:33Z

seems to me that the correct solution to this problem is to allow pip to use an external service

That seems to me like a much bigger change than the simple "report on backtracking" that's being discussed here. If you think that's worthwhile, feel free to try to develop such a thing and propose a PR, but I'm skeptical that's likely to be practical (speaking as one of the people who developed the current resolver, and hence has a feel for the scale of such a job).

potiuk · 2022-03-02T19:32:49Z

I perfectly understand that we cannot decide upfront, and yeah - it is an extremely complex problem to solve, so I also sympathise with pip maintainers here.

But if the algorithm cannot decide, let the user decide when they want to stop and how much of backtracking to do and when "too long" or "too much" of the backtracking to do. I am fine with either "time based" limit or "iteration based" or any other limit that will be "reasonable" from implementation point of view. But simply letting it running for an indefinite amount of time when things go wrong is the "worst" UI choice from the user perspective. Because the user cannot do anything about it when it happens.

While I understand that it's extremely "hard" to decide when "long" is "too long" (this is the problem pip maintainers have and I understand it is difficult), delegating it to the user (if they choose to) is the next best thing that can be done. Most of the users do not have "generic" problem to solve. They just want to make sure their particular command works - and if they use it in CI context especially, this is much "narrower" problem space (because they repetitively run pretty much the same command and they expect similar output) and they can make much better decisions for their particular case than the "generic" solution and they can decide on their own when "long" is "too long". And then they should get the right diagnostic information if they hit the limit.

This is what I propose - give the users (those who need it - should be optional) the ability to make their own decision when "long" is "too long" for their particular case, and print diagnostics information if this limit is hit.

I think not all decisions have to be made by the algorithm and pip maintainers - some of those can simply be delegated to users who need it and know what they are doing.

pradyunsg · 2022-03-02T19:39:19Z

some of those can simply be delegated to users who need it and know what they are doing.

The users who know what they're doing can already do whatever they want: pass --no-deps and pip will install exactly what you've asked for.

There's two avenues to improve this from, IMO, giving users a knob for "stop backtracking after X attempts" and "present more information when we start backtracking". This is purely intended for the latter, and if someone wants to ask for the former, that's a separate discussion.

I'm gonna bow out from this one, since I think my energy is better spent elsewhere. :)

@nadavwe If you update this PR, please @-mention me! :)

potiuk · 2022-03-02T20:32:03Z

The users who know what they're doing can already do whatever they want: pass --no-deps and pip will install exactly what you've asked for.

Just to clarify a bit - because it was maybe a misunderstanding. I do want to tap into the powers of pip resolver. I value the work done by pip maintainers on making it work and I actually need it. --no-deps is not what I or most of the users who hit long backtracking issue want, I want to be able to just know when it happens and have reasonable way of handling it on my side as a user (In the - rather unlikely but sometimes happening - event when pip cannot make those decisions for me.

There's two avenues to improve this from, IMO, giving users a knob for "stop backtracking after X attempts" and "present more information when we start backtracking". This is purely intended for the latter, and if someone wants to ask for the former, that's a separate discussion.

Surely if you say so. Happy to open it.

potiuk · 2022-03-02T21:15:09Z

I submitted a new issue about timeout separating it out from this one #10932

malthe · 2022-03-02T22:17:42Z

@astrojuanlu oh I meant both: immediate feedback and a summary at the end – and this should also be generated if the program is interrupted.

malthe · 2022-03-02T22:26:36Z

@pfmoore why wouldn't a resolver service be practical given that we're asking all clients to do exactly that? This is a digression of course, but the point is to clarify that the current practice is not an optimal solution. It's basically the gentoo of package distribution – everyone compiles their own. Perhaps the analogy doesn't hold all the way, but if you've used a binary distribution, you appreciate the difference in installation time.

I think there is a scope now to this which is to "present found conflicts when trying to resolve them". Then we've got a timeout spinoff in #10932 and one can imagine some toggles to control the behavior of the backtracking system in a future issue.

pfmoore · 2022-03-02T22:56:04Z

@pfmoore why wouldn't a resolver service be practical

Maybe it would. If you want to write a PR that demonstrates how it would work, I'd be happy to be proved wrong. I just don't personally know how you'd do something like that, in a way that would be any better than the current resolver. But let's not endlessly debate this - I'll keep an open mind until someone produces a PR.

notatallshaw · 2022-03-03T00:22:14Z

I'm gonna bow out from this one, since I think my energy is better spent elsewhere. :)

@pradyunsg okay but with regards to this PR and not the extended discussion do you have any blocking requirements before it's merged?

As discussed capturing KeyboardInterupt does not help situations where this impacts CI users, which seems to be the majority of users complaining they can't debug backtracking situations. Also as I mention in #10258 (comment) it doesn't help users that don't realize backtracking happened and they're not sure why old versions of packages were installed.

Would you accept the compromise I proposed in #10258 (comment) ?

malthe · 2022-03-03T06:15:26Z

@pfmoore now that I'm properly reading up on this, I can see how there are certain details ... that make the problem quite hard: https://dustingram.com/articles/2018/03/05/why-pypi-doesnt-know-dependencies/.

But of course with today's cloud tech, not exactly impossible.

Fixes pypagh-9254. Closes pypagh-10258. See pypa#10258 (comment) for inspiration.

astrojuanlu · 2022-03-03T10:59:29Z

I've been completely nerd-sniped and I rage-implemented an alternative in gh-10937, hopefully encoding @pradyunsg ideas from his first rejection to this attempt. I will complete the description later, I have to... get back to what I was supposed to do.

Edit: I now wrote a proper summary.

astrojuanlu · 2022-03-04T11:03:22Z

Okay, looks like gh-10937 was deemed a reasonable approach to tackle this issue. I think the output now is much more informative, as it captures the conflicts right as they appear, and then the user can (a) Ctrl-C whenever they want if they are in an interactive session, or (b) inspect the output afterwards if they are debugging a slow CI build. Still deciding "how often the warnings are presented and what their verbosity + presentation style should be", but this is how it looks now:

root@bd046670c282:/opt/airflow# pip install ".[devel_all]" --upgrade --upgrade-strategy eager "dill<0.3.3" "certifi<2021.0.0" "google-ads<14.0.1"
Processing /opt/airflow
  Preparing metadata (setup.py) ... done
...
Collecting elasticsearch>7
  Downloading elasticsearch-7.17.1-py2.py3-none-any.whl (385 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 385.8/385.8 KB 6.7 MB/s eta 0:00:00
Requirement already satisfied: curlify>=2.1.0 in /usr/local/lib/python3.7/site-packages (from facebook-business>=6.0.2->apache-airflow==2.3.0.dev0) (2.2.1)
Requirement already satisfied: aiohttp in /usr/local/lib/python3.7/site-packages (from facebook-business>=6.0.2->apache-airflow==2.3.0.dev0) (3.8.1)
Requirement already satisfied: pycountry>=19.8.18 in /usr/local/lib/python3.7/site-packages (from facebook-business>=6.0.2->apache-airflow==2.3.0.dev0) (22.1.10)
INFO: Will try a different candidate, due to conflict:
    apache-airflow[devel-all] 2.3.0.dev0 depends on importlib_metadata>=1.7
    apache-airflow[devel-all] 2.3.0.dev0 depends on importlib-metadata>=4.4
    nox 2020.12.31 depends on importlib-metadata; python_version < "3.8"
    alembic 1.7.6 depends on importlib-metadata; python_version < "3.9"
    argcomplete 1.12.3 depends on importlib-metadata<5 and >=0.23; python_version == "3.7"
    click 8.0.4 depends on importlib-metadata; python_version < "3.8"
    flake8 4.0.1 depends on importlib-metadata<4.3; python_version < "3.8"
Collecting flake8>=3.6.0
  Downloading flake8-4.0.0-py2.py3-none-any.whl (64 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 64.1/64.1 KB 14.5 MB/s eta 0:00:00
INFO: Will try a different candidate, due to conflict:
    apache-airflow[devel-all] 2.3.0.dev0 depends on importlib_metadata>=1.7
    apache-airflow[devel-all] 2.3.0.dev0 depends on importlib-metadata>=4.4
    nox 2020.12.31 depends on importlib-metadata; python_version < "3.8"
    alembic 1.7.6 depends on importlib-metadata; python_version < "3.9"
    argcomplete 1.12.3 depends on importlib-metadata<5 and >=0.23; python_version == "3.7"
    click 8.0.4 depends on importlib-metadata; python_version < "3.8"
    flake8 4.0.0 depends on importlib-metadata<4.3; python_version < "3.8"

Folks are welcome to try it out and see if it helps debugging backtracking situations.

potiuk · 2022-03-04T17:32:03Z

Folks are welcome to try it out and see if it helps debugging backtracking situations.

This looks fantastic. I am a bit swamped now but I can try to reproduce some of the recent cases we had with this version and see if this will aid in siimilar problem resolution (but from the quick look it should be extremely helpful).

Fixes pypagh-9254. Closes pypagh-10258. See pypa#10258 (comment) for inspiration.

nadavwe force-pushed the start-backtracking branch from c24e359 to a9ef2de Compare August 2, 2021 13:27

nadavwe commented Aug 2, 2021

View reviewed changes

src/pip/_vendor/resolvelib/resolvers.py Outdated Show resolved Hide resolved

nadavwe commented Aug 2, 2021

View reviewed changes

notatallshaw mentioned this pull request Aug 29, 2021

Max Backtracking Option and print out current failure casues #10417

Open

github-actions bot added the needs rebase or merge PR has conflicts with current master label Oct 9, 2021

nadavwe mentioned this pull request Oct 11, 2021

start_backtracking suggestion sarugaku/resolvelib#81

Merged

nadavwe mentioned this pull request Oct 19, 2021

updating resolvelib version to include new reporter interface #10600

Merged

nadavwe force-pushed the start-backtracking branch from d19c4f8 to 5047743 Compare October 24, 2021 10:33

pypa-bot removed the needs rebase or merge PR has conflicts with current master label Oct 24, 2021

nadavwe changed the title ~~add message when backtracking starts~~ add message when resolving conflicts Oct 24, 2021

nadavwe changed the title ~~add message when resolving conflicts~~ present found conflicts when trying to resolve them Oct 24, 2021

uranusjr reviewed Oct 25, 2021

View reviewed changes

uranusjr approved these changes Oct 25, 2021

View reviewed changes

nadavwe force-pushed the start-backtracking branch from 3266df7 to 7ad1da1 Compare November 8, 2021 10:07

github-actions bot added the needs rebase or merge PR has conflicts with current master label Nov 12, 2021

potiuk mentioned this pull request Mar 2, 2022

Give the user (optional) control over the backtracking behaviour via timeout #10932

Open

1 task

malthe mentioned this pull request Mar 3, 2022

Poetry is extremely slow when resolving the dependencies python-poetry/poetry#2094

Closed

3 tasks

astrojuanlu added a commit to astrojuanlu/pip that referenced this pull request Mar 3, 2022

Present found conflicts when discarding some criterion

f47bc88

Fixes pypagh-9254. Closes pypagh-10258. See pypa#10258 (comment) for inspiration.

astrojuanlu mentioned this pull request Mar 3, 2022

Present found conflicts when discarding some criterion #10937

Merged

tstadel mentioned this pull request Mar 15, 2022

Lost in backtracking: backtracking does not finish successfully #10965

Closed

1 task

github-actions bot added the needs rebase or merge PR has conflicts with current master label Feb 7, 2023

astrojuanlu added a commit to astrojuanlu/pip that referenced this pull request Feb 27, 2023

Present found conflicts when discarding some criterion

7c82696

Fixes pypagh-9254. Closes pypagh-10258. See pypa#10258 (comment) for inspiration.

astrojuanlu added a commit to astrojuanlu/pip that referenced this pull request Mar 26, 2023

Present found conflicts when discarding some criterion

6930066

Fixes pypagh-9254. Closes pypagh-10258. See pypa#10258 (comment) for inspiration.

pradyunsg closed this in #10937 Mar 26, 2023

github-actions bot locked as resolved and limited conversation to collaborators Apr 11, 2023

		@@ -0,0 +1 @@
		found conflicts are output before pip delves into version resolution.

	found conflicts are output before pip delves into version resolution.
	Display found conflicts are before pip delves into version resolution.

Present found conflicts when trying to resolve them #10258

Present found conflicts when trying to resolve them #10258

Conversation

nadavwe commented Aug 2, 2021 • edited by pradyunsg Loading

nadavwe Aug 2, 2021

Choose a reason for hiding this comment

uranusjr commented Aug 7, 2021

nadavwe commented Aug 8, 2021

notatallshaw commented Aug 29, 2021

nadavwe commented Sep 1, 2021

notatallshaw commented Sep 1, 2021

notatallshaw commented Sep 15, 2021

nadavwe commented Sep 29, 2021 • edited Loading

notatallshaw commented Sep 29, 2021

uranusjr Oct 25, 2021

Choose a reason for hiding this comment

nadavwe Oct 25, 2021

Choose a reason for hiding this comment

uranusjr Oct 25, 2021

Choose a reason for hiding this comment

nadavwe Oct 25, 2021

Choose a reason for hiding this comment

uranusjr Oct 25, 2021

Choose a reason for hiding this comment

nadavwe commented Oct 25, 2021

uranusjr commented Oct 25, 2021

nadavwe commented Oct 25, 2021

uranusjr Oct 25, 2021

Choose a reason for hiding this comment

nadavwe commented Oct 25, 2021

pradyunsg commented Oct 26, 2021

nadavwe commented Nov 8, 2021

malthe commented Mar 2, 2022

pfmoore commented Mar 2, 2022

malthe commented Mar 2, 2022

pfmoore commented Mar 2, 2022

william-silversmith commented Mar 2, 2022

malthe commented Mar 2, 2022

astrojuanlu commented Mar 2, 2022

pfmoore commented Mar 2, 2022

potiuk commented Mar 2, 2022 • edited Loading

pradyunsg commented Mar 2, 2022

potiuk commented Mar 2, 2022

potiuk commented Mar 2, 2022

malthe commented Mar 2, 2022

malthe commented Mar 2, 2022

pfmoore commented Mar 2, 2022

notatallshaw commented Mar 3, 2022

malthe commented Mar 3, 2022

astrojuanlu commented Mar 3, 2022 • edited Loading

astrojuanlu commented Mar 4, 2022

potiuk commented Mar 4, 2022

nadavwe commented Aug 2, 2021 •

edited by pradyunsg

Loading

nadavwe commented Sep 29, 2021 •

edited

Loading

potiuk commented Mar 2, 2022 •

edited

Loading

astrojuanlu commented Mar 3, 2022 •

edited

Loading