pipenv lock fails when a dependent package depends on an another package served on non-default pypi server with pipenv 2022.4.8

Issue description

We have a Pipfile like this, which installs mypackage from our private pypi server.

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[[source]]
name = "private"
url = "private pypi URL"
verify_ssl = true

[packages]
mypackage = {version = "==X.Y.Z", index = "private"}

[requires]
python_version = "3.8"

In setup.py of mypacakge, it depends on an another package named myanotherpackage and served on the same private pypi server.

setup(
    name="mypackage",
    version="X.Y.Z",
    install_requires=["myanotherpackage==A.B.C"],
    dependency_links=["private pypi URL"],
)

We’d like to update the dependencies by running pipenv lock.

Expected result

pipenv lock works fine and updates Pipfile.lock.

Actual result

With pipenv 2022.4.8, pipenv lock shows an error like this. Note that the package names and their versions are manually edited.

CRITICAL:pipenv.patched.notpip._internal.resolution.resolvelib.factory:Could not find a version that satisfies the requirement myanotherpackage==A.B.C (from mypackage) (from versions: 0.0.0)
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 822, in _main
[ResolutionFailure]:       resolve_packages(
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 771, in resolve_packages
[ResolutionFailure]:       results, resolver = resolve(
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 751, in resolve
[ResolutionFailure]:       return resolve_deps(
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/utils/resolver.py", line 1066, in resolve_deps
[ResolutionFailure]:       results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/utils/resolver.py", line 862, in actually_resolve_deps
[ResolutionFailure]:       resolver.resolve()
[ResolutionFailure]:   File "/usr/local/lib/python3.8/site-packages/pipenv/utils/resolver.py", line 663, in resolve
[ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: No matching distribution found for myanotherpackage==A.B.C

WIth 2022.3.28, it works fine.

Steps to replicate

Just follow the steps described above if you have an alternative pypi server.

---

I’m sorry but I cannot paste the result of $ pipenv --support here as it contains the real name of the packages.

[juanitosvq]

I got here from #5021 - @matteius, the docs seem to describe pretty accurately what the new behaviour is, so thanks for that!

I would agree with @JacobHayes that having to maintain all those internal dependencies in the Pipfile of your application seems wrong. Even if we only had to do it whenever a dependency is added/removed.

We’ve temporarily pinned our pipenv version, but we will have to look into mirroring the pypi dependencies into our internal repo. It would be great to see, however, if it would be possible to specify the index in the setup.py of the library and have the resolver know in which index to find those internal dependencies, avoiding this way having to mirror pypi.

[JacobHayes]

I just ran into this today too after upgrading. I’d rather not duplicate dependencies in both setup.py and Pipfile as we then have to maintain both files, eg: when bumping minimum versions, adding new deps, or removing deps (we have a lot of internal packages + transitive deps, so it’d be quite noisy).

This seems like a regression (I may have missed things in release notes) - any chance this could be reopened until a fix is in place? Thanks for the hard work on pipenv!

note: interestingly, this does seem to work ok on 2022.3.28, even though that’s when the behavior seems to have changed, as per https://pipenv.pypa.io/en/latest/advanced/#specifying-package-indexes:

Starting in release 2022.3.23 all packages are mapped only to a single package index for security reasons. All unspecified packages are resolved using the default index source; the default package index is PyPI.