Support force resolving dependency versions a la yarn's "resolutions" support.

Is your feature request related to a problem? Please describe.

GitHub is complaining that a transitive dependency has a vulnerability and I see no way in pipenv to force a resolution in the same way I currently can in the javascript ecosystem with yarn (https://classic.yarnpkg.com/en/docs/selective-version-resolutions/).

I’m using ScoutSuite which in turn relies on oci which relies on a version of cryptography that GitHub considers vulnerable. It looks like oci has no immediate plans to upgrade this bad dependency (https://github.com/oracle/oci-python-sdk/pull/299). Since I don’t use Oracle cloud, I’m happy if the oci dependency from ScoutSuite doesn’t work. I just want to force update this dependency to resolve to version >= 3.2 where the issue is resolved.

Describe the solution you’d like

A resolutions section of the pipfile equivalent to yarn’s resolutions section which behaves in the same way during install/resolution.

Describe alternatives you’ve considered

The only viable alternative I see is to fork one or both of the repos above and make the necessary changes myself - way too much effort for what should be a one-line change in my local pipfile.

Additional context

N/A

[mstrofbass]

One of the jokes I make about the Python ecosystem is how all the library maintainers think they can do a better job solving problems that have been long solved by similar libraries in other languages and inevitably release a far inferior product.

[chris-codaio]

I’m quite happy to take the risk in this case. That said, here are the reasons you might want to do this (from Yarn’s site):

1. You may be depending on a package that is not updated frequently, which depends on another package that got an important upgrade. In this case, if the version range specified by your direct dependency does not cover the new sub-dependency version, you are stuck waiting for the author.

2. A sub-dependency of your project got an important security update and you don’t want to wait for your direct-dependency to issue a minimum version update.

3. You are relying on an unmaintained but working package and one of its dependencies got upgraded. You know the upgrade would not break things and you also don’t want to fork the package you are relying on, just to update a minor dependency.

4. Your dependency defines a broad version range and your sub-dependency just got a problematic update so you want to pin it to an earlier version.