Relaxing / Ignoring constraints during dependency resolution

[stonebig]

What's the problem this feature will solve?
Puting together some packages that have by default incompatible constraints.

Indeed:

• constraints are often meant by the package maintainer as:
  . "accepting complains on this known/focus set of package",
  . you're on your own support if you deviate, but not necessarly bad.
• packages rarely focus on the same versions of complementary packages.
  ==> The new resolver may create more problems than solutions, when trying to build an environment with a large set of package.

Describe the solution you'd like
Be able to ignore voluntary some constraints

Wish:

• we can put some "relax" rule to over-rule too strict packages (for our need), because we know what we want:
  pip install Spyder --relax relaxrules.r , with relax file below meaning:
  . if you want PyQt5, it must be 5.14.x
  . if you want Jedi, it must be >=0.16

PyQt5~=5.14
Jedi>=0.16

Alternative Solutions
Today:

• I have to manually recompile from source "too strict" packages, to workaround this,
• or I would have to build one virtualenv per package,
• or I would only be able to use a specific Python distribution, with much older packages and Python version.

Additional context
Maintaining WinPython

** Current pip check **

• datasette 0.39 has requirement Jinja2~=2.10.3, but you have jinja2 2.11.2.
• astroid 2.3.3 has requirement wrapt==1.11.*, but you have wrapt 1.12.1.

** Current workaround **

• Spyder manually recompiled to accept :
  . PyQt5-5.14.2 (as pip doesn't have a "long term support" of PyQt5-5.12, so the fresher version is safer)

other wishes:

• a basic GUI on Pip (tkinter or web) would still be nice, to have a better view of all the coming version conflicts.

[uranusjr]

@stonebig Would you mind separate the other wishes part into their own issues? It would be much easier to discuss them that way.

As for relxing, I am honestly uncomfortable with having such a impactful feature handy for the general audience. I was by chance also having a similar discussion in the Pipenv tracker, and both the Pipenv one and your are exactly situations I personally think the maintainers have a valid point to restrict the versions, and a user should not be able to override them easily. It’s still useful to have this option somewhere since indeed there are packages with incorrect metadata out there, but pip is too low in the packaging management realm to implement the feature IMO.

[stonebig]

Ok, separating other whishes in a few minutes.
this is moved on another issue:

- having the beautifull "pipdeptree" features in the standard pip:
    . a beautifull description of what package needs (or is needed) by what package of what version,
    . the possibility to get that programatically as json answers.

[pradyunsg]

Thanks for filing this @stonebig! I've gone ahead and re-titled this to issue to be more clearly scoped.

We have seen multiple groups of users express interest in a feature like this. @pfmoore @uranusjr and I have had this come up in our discussions during our work on the resolver, and we are aware of this user need.

We don't know how exactly this would work and what approach we'd be taking here -- we're gonna visit this specific topic at a later date, once the new resolver implementation is at feature parity with the current resolver.

[pradyunsg]

a basic GUI on Pip (tkinter or web) would still be nice, to have a better view of all the coming version conflicts.

This is a completely separate request, and can be built outside of pip and doesn't need to be built into pip. If someone wants to build this outside of pip and later propose bringing it into pip (with clear reasoning for why it can't live outside pip), that'd be perfect. I don't think pip's maintainers are going to be developing/integrating this into pip, and I welcome others to try to build such tooling on-top-of or outside of pip.

I think there has been a "pip GUI" project undertaken as part of IDLE in the past, but I don't have the time to take a look right now. :)

[stonebig]

I hope that in the new resolver project, easy to use functions will be provided to facilitate emergence of a GUI project