REGR: pipenv sync StopIteration error with 2022.11.05

[snowman2]

Note: Works fine with pipenv==2022.10.25

Issue description

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 to suppress this warning.
Installing dependencies from Pipfile.lock (e67ab7)...
Traceback (most recent call last):
  File "/opt/venv/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/cli/options.py", line 57, in main
    return super().main(*args, **kwargs, windows_expand_args=False)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/decorators.py", line 84, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/vendor/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/opt/venv/lib/python3.9/site-packages/pipenv/cli/command.py", line 646, in sync
    retcode = do_sync(
  File "/opt/venv/lib/python3.9/site-packages/pipenv/core.py", line 3145, in do_sync
    do_init(
  File "/opt/venv/lib/python3.9/site-packages/pipenv/core.py", line 1378, in do_init
    do_install_dependencies(
  File "/opt/venv/lib/python3.9/site-packages/pipenv/core.py", line 888, in do_install_dependencies
    batch_install(
  File "/opt/venv/lib/python3.9/site-packages/pipenv/core.py", line 742, in batch_install
    install_source = next(filter(lambda s: s["name"] == index_name, sources))
StopIteration

Expected result

No failure.

Actual result

StopIteration

Steps to replicate

pipenv sync --dev

Operating System: Ubuntu 20.04 LTS
Python Version: 3.9

[matteius]

@snowman2 does the source have an index name and is it specified in the lock file for the package which index to use? When is the last time you updated your lock file? Just trying to get a sense for this issue.

[snowman2]

When is the last time you updated your lock file?

Today, using the latest pipenv.

[snowman2]

does the source have an index name

Yes

[matteius]

@snowman2 You certainly aren't providing enough details for me to triage and solve this ticket, no example Pipfile or or lock file or anything.

and is the index name specified in the lock file for the package that its failing on?

[snowman2]

I cannot provide that unfortunately and haven't had a chance to produce a minimal reproducible example. Just enough time to raise the issue. I will try to provide one when I get a free moment.

[snowman2]

Here is a minimal Pipfile:

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

[[source]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cpu"
verify_ssl = true

[dev-packages]
pytest = {version = "*",index = "pypi"}

[packages]
aiobotocore = {extras=["boto3"], version = "*",index = "pypi"}
torch = {version = "*", index = "torch"}

[requires]
python_version = "3.9"

I can run:

pipenv lock
pipenv sync --dev

And I can see the issue.

[snowman2]

Oh, I see the issue - the index name doesn't match the source name in the Pipfile.

torch != pytorch

[tonispring]

Ideally pipenv could raise with a message about the issue when it encounters a name mismatch, we ran into the same problem and it was confusing finding the cause since it required understanding the pipenv source code that was raising StopIteration

[matteius]

@snowman2 I wonder how its possible for the Pipfile.lock to end up with different source names that the Pipfile? I wonder if it possibly relates to the bug of issue #5456

Ideally pipenv could raise with a message about the issue when it encounters a name mismatch, we ran into the same problem and it was confusing finding the cause since it required understanding the pipenv source code that was raising StopIteration

@tonispring I think we can do that -- let's track that work in this issue report.

[snowman2]

I wonder how its possible for the Pipfile.lock to end up with different source names that the Pipfile?

The problem originated from the Pipfile with incorrect index.