Error "KeyError: 'name'" in pipenv install (from Release v2022.3.23)

[masato-yasuda]

From Release v2022.3.23 which was updated today, we've started to receive the following error("KeyError: 'name'"). in pipenv install..

Traceback (most recent call last):
  File "/usr/local/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/pipenv/cli/options.py", line 54, in main
    return super().main(*args, **kwargs, windows_expand_args=False)
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/decorators.py", line 84, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/pipenv/cli/command.py", line 193, in install
    do_install(
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 1978, in do_install
    do_init(
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 1244, in do_init
    do_install_dependencies(
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 808, in do_install_dependencies
    batch_install(
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 715, in batch_install
    c = pip_install(
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 1406, in pip_install
    extra_indexes = list(filter(lambda d: d['name'] == requirement.index, project.sources))
  File "/usr/local/lib/python3.8/site-packages/pipenv/core.py", line 1406, in <lambda>
    extra_indexes = list(filter(lambda d: d['name'] == requirement.index, project.sources))
KeyError: 'name'
error building image: error building stage: failed to execute command: waiting for process to exit: exit status 1

Our environement is docker and part of our Dockerfile is the following

FROM python:3.8-slim-buster AS backend-builder

...(Skip)..

RUN pip install --upgrade pip && \
    pip install pipenv && \
    pipenv install --system --deploy <-- Got the error

We guess that it is caused by the following update. Could you check and fix it?
#4983

[matteius]

@masato-yasuda Please provide a sample Pipfile It appears you are specifying an index but not by name, I would like to see how this is done as we have no unit tests around it.

[masato-yasuda]

@matteius
The following is our sample Pipfile.

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

[[source]]
url = "https://${mysecret}@mydomain/pypi/simple"
verify_ssl = false

[packages]
mypackage = "*"

[matteius]

Thanks @masato-yasuda I suggest using the prior version for now since this affects you, and I will be looking into the proper fix.

[matteius]

@masato-yasuda Sorry for the fast follow ping, but I am wondering would it be possible to provide a name to your second source in the Pipfile? The example didn't fail for me, because I don't have a private source with a package that actually resolves to it, but I think that is the issue and I am not sure we can support index matching if the source isn't named though. I will think more about if there is a safer fallback to do.

[masato-yasuda]

@matteius
Thanks for your quick response. After providing a name to the second source in the Pipfile, it works. However, we cannot apply this change easily (because there are many Pipfiles) so we hope that it will work without chaning our current Pipfile..

[matteius]

@masato-yasuda Would you be able to try this branch and let me know if it works: #5004
I'm still trying to come up with a valid test case, but I have some more thoughts on that.

[matteius]

I've added a unit test as well in my branch that fails on main but passed with this fix. It appears there was not an issue with locking but there was an issue during install, so noting that as well.

[masato-yasuda]

@matteius
Thanks for your fix! Let me check the branch tomorrow..

[masato-yasuda]

@matteius
We tried the next version (v2022.3.24) and confirmed that our CI process becomes working again. Thanks very much for your quick fix!