Add hint when resolution impossible causes have no versions available

[notatallshaw]

I have seen this as a common cause for confusion when hitting ResolutionImpossible errors, the are no packages available for a particular dependency or transitive dependency on a user's platform, but the resolution impossible message does not make that clear.

Here is an older example, nuclia/nucliadb#977, running a similar command:

pip install --dry-run --platform win_amd64 --only-binary=":all:" "nucliadb>=2.0"

Produces a very long error message with a lot of:

The conflict is caused by:
    nucliadb 6.4.0.post4192 depends on lru-dict>=1.1.7
    nucliadb 6.4.0.post4184 depends on lru-dict>=1.1.7
    nucliadb 6.4.0.post4176 depends on lru-dict>=1.1.7
    nucliadb 6.4.0.post4171 depends on lru-dict>=1.1.7
   ...
    nucliadb 2.0.5 depends on nucliadb-node-binding>=0.3.0
    nucliadb 2.0.4 depends on nucliadb-node-binding>=0.3.0
    nucliadb 2.0.3 depends on nucliadb-node-binding>=0.3.0
    nucliadb 2.0.2 depends on nucliadb-node-binding>=0.2.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency conflict

This PR adds a strong hint to the user the issue is that given their platform there aren't any packages to select:

Some conflict cause(s) have no available versions for your environment:
    lru-dict
    nucliadb-node-binding

An alternative solution would be evaluate how many candidates are available for each cause and add a note into the conflict is caused by message, e.g.

    nucliadb 6.4.0.post4171 depends on lru-dict>=1.1.7 (no versions available)
   ...
    nucliadb 2.0.5 depends on nucliadb-node-binding>=0.3.0 (no versions available)

This could be more informative in some situations, but I don't think the messaging is as clear or obvious.

[pradyunsg]

Could you add a test for this behaviour?

[notatallshaw]

Added a test.

Also, I got rid of filtering yanked packages (as the requirement could be =={yanked-version}) and I've updated the wording to be even more explicit:

Additionally, some conflict causes have no available versions for your environment:
    lru-dict
    nucliadb-node-binding

Separately, I think I've come up with a good idea for showing individual requirements have no versions available, but the logic will be a bit more complicated, and I don't think it will negate this being a helpful hint to users, so I follow up with another PR when I have time.

[notatallshaw]

I reworded the hint again (writing is hard), to try and make clear it's the project as whole that has no matching distributions, not just the specific requirements listed above:

Additionally, some projects in these conflicts have no matching distributions available for your environment:
    lru-dict
    nucliadb-node-binding

I will stop updating now, unless someone reviews and provides a better suggestion. Otherwise I think this is ready.

[ichard26]

At some point, I would like to improve the no distributions found error to give hints at WHY no distributions were found. This is linked in with my (stalled) effort to improve "this wheel is not compatible on this platform" errors.

This is a good improvement on its own, but if pip ever gains a better "no distributions were found" error, it'd be good to use the same error reporting machinery.

[notatallshaw]

@ichard26 I 100% agree, WHY should be the ultimate goal of resolution impossible errors.

This is an improvement on the WHAT, broadening the number of cases where users can have enough information to try and manually figure out the WHY themselves.

I think this WHAT and WHY is a good way of framing these errors, and I have a future improvement in mind now to the WHAT some time after this lands.