Injecting credentials broken

[dhonorez]

Issue description

Upgrading to the latest version of pipenv via HomeBrew breaks injecting credentials using environment variables.

Expected result

pipenv install installs dependencies from private repositories.

Actual result

[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv run pip install <requirement_name> to bypass this mechanism, then run $ pipenv graph to inspect the versions actually installed in the virtualenv.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.

Steps to replicate

pipenv install

[eht16]

We experience a similar issue: after upgrading to 2023.8.26, pipenv lock fails with the error message above.
However, pipenv install with a previously created Pipfile.lock still works.

We are using 90 packages from PyPI and one package from a private Gitlab package index.

Unfortunately I cannot share the private registry (it's private :D) but a sample Pipfile which triggers the problem:

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

[[source]]
name = "gitlab"
url = "https://${GITLAB_REGISTRY_PYPI_USER}:${GITLAB_REGISTRY_PYPI_TOKEN}@gitlab.REDACTED.com/api/v4/projects/REDACTED/packages/pypi/simple"
verify_ssl = true


[packages]
some-private-package = {version = "==1.23.42", index = "gitlab"}

[requires]
python_version = "3.10"

[matteius]

@dhonorez Would be helpful to know which kind of dependencies are affected -- I am assuming vcs, but I think there are tests around this, do you have an example Pipfile entry?

EDIT @eht16 thanks for an example.

[matteius]

Also, do you know if this just started in 2023.8.26 or if it started in the august releases?

[eht16]

We just tested 2023.8.25 and it is working fine.

[dhonorez]

@matteius The entry that fails is the following:
woodwing-client = { version = "==12.2.0", index = "artifactory" }

The artifactory index is declared in the pipfile:

[[source]]
url = "https://${ARTIFACTORY_AUTH}@${ARTIFACTORY_URL}"
verify_ssl = true
name = "artifactory"

I think our scenario is pretty much identical to that from @eht16

[matteius]

Hmm, I just subbed out part of my pytorch index with an env var and it seemed to work fine:

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

[[source]]
url = "https://${PYTORCH}/whl/cu117"
verify_ssl = true
name = "downloadpytorch"

[packages]
torch = {version = "==2.0.1", index = "downloadpytorch"}

[dev-packages]

[requires]
python_version = "3.11"

I am not sure where its breaking in your case -- anything stand out in the diff? v2023.8.25...v2023.8.26

My hunch is maybe the cached_property is causing it, but I am honestly at a loss currently without being able to reproduce it.

[dhonorez]

@matteius is your private repo protected with authentication? Because I read pipenv does something to hash the credentials that are provided, I suspect maybe something goes wrong while hashing?

[matteius]

is your private repo protected with authentication?

No, this is just the public pytorch repo, I thought this has something to do with using an env var in the source URL.

I read pipenv does something to hash the credentials that are provided, I suspect maybe something goes wrong while hashing?

I am not sure -- do you have a link to this topic?

Just from a code perspective, it has to be something that changed in that diff between .25 and .26 ... nothing stands out in that department to me yet.

[dhonorez]

is your private repo protected with authentication?

No, this is just the public pytorch repo, I thought this has something to do with using an env var in the source URL.

It's definitely an issue with credentials, not with injecting env vars.

I read pipenv does something to hash the credentials that are provided, I suspect maybe something goes wrong while hashing?

I am not sure -- do you have a link to this topic?

https://pipenv.pypa.io/en/latest/credentials/#injecting-credentials-into-pipfile-via-environment-variables

Just from a code perspective, it has to be something that changed in that diff between .25 and .26 ... nothing stands out in that department to me yet.

[matteius]

Are you able to check if this fixes it? #5882

I am not 100% sure it will, but of any change between 25 and 26 this is my hunch. 🍿

[pinguin999]

@matteius No it is the other cached_property that's causing the bug. 8716271#diff-62e85156fc3b274046cc03dabfe6e3ceead503f330b98fb3611645216b4b6e1fR301

[matteius]

Thanks @pinguin999 I made the change -- but added back cached_property on the other method -- would be nice to know that will work (or do both methods need the cached_property removed)?

[pinguin999]

It worked for me with only changing back the 8716271#diff-62e85156fc3b274046cc03dabfe6e3ceead503f330b98fb3611645216b4b6e1fR301
(But we do not use use_pep517 so I think the pip_args cache was not tested.)