Pipenv searches virtual environment's python binary in wrong path #5109

elegos · 2022-05-22T20:20:05Z

Hello,

I'm having trouble using Pipenv lately. In particular, after I updated my OS (Fedora 36), pipenv during the install command tries to search the python binary inside {local_virtualenv}/local/bin/python, while the symlink to python is in {local_virtualenv}/bin/python. I tried to remove and reinstall the virtual environment (pipenv --rm and pipenv install), but the problem persists.

Application versions

➜  etl git:(develop) pip --version
pip 22.1.1 from /home/gfurlan/.local/lib/python3.10/site-packages/pip (python 3.10)
➜  etl git:(develop) pipenv --version
pipenv, version 2022.5.2
➜  etl git:(develop) python --version
Python 3.10.4
➜  etl git:(develop) which python
/usr/bin/python

Pipenv install

➜  etl git:(develop) pipenv install -d
Creating a virtualenv for this project...
Pipfile: /home/gfurlan/src/project/glue/etl/Pipfile
Using /usr/bin/python3.7m (3.7.13) to create virtualenv...
⠙ Creating virtual environment...created virtual environment CPython3.7.13.final.0-64 in 89ms
  creator CPython3Posix(dest=/home/gfurlan/.local/share/virtualenvs/etl-XCf49Mm9, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/gfurlan/.local/share/virtualenv)
    added seed packages: pip==22.0.4, setuptools==62.1.0, wheel==0.37.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment!
Traceback (most recent call last):
  File "/home/gfurlan/.local/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/cli/options.py", line 56, in main
    return super().main(*args, **kwargs, windows_expand_args=False)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/decorators.py", line 84, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/cli/command.py", line 222, in install
    do_install(
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/core.py", line 1965, in do_install
    ensure_project(
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/core.py", line 553, in ensure_project
    ensure_virtualenv(
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/core.py", line 486, in ensure_virtualenv
    do_create_virtualenv(
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/core.py", line 1013, in do_create_virtualenv
    project._environment = Environment(
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/environment.py", line 70, in __init__
    self._base_paths = self.get_paths()
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/environment.py", line 394, in get_paths
    c = subprocess_run(command)
  File "/home/gfurlan/.local/lib/python3.10/site-packages/pipenv/utils/processes.py", line 75, in subprocess_run
    return subprocess.run(
  File "/usr/lib64/python3.10/subprocess.py", line 501, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib64/python3.10/subprocess.py", line 966, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib64/python3.10/subprocess.py", line 1842, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/gfurlan/.local/share/virtualenvs/etl-XCf49Mm9/local/bin/python'

pipenv shell and echo $PATH:

➜  etl git:(develop) pipenv shell
Launching subshell in virtual environment...
 . /home/gfurlan/.local/share/virtualenvs/etl-XCf49Mm9/bin/activate
➜  etl git:(develop)  . /home/gfurlan/.local/share/virtualenvs/etl-XCf49Mm9/bin/activate
(etl) ➜  etl git:(develop) echo $PATH
/home/gfurlan/.local/share/virtualenvs/etl-XCf49Mm9/bin:/home/gfurlan/.local/bin:/home/gfurlan/.local/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

As you can see the PATH variable is correctly set, though pipenv tries to use the local prefix for calling python for some reason.

May you please help me sorting this out?

Thanks

EDIT: I think I got the point where the issue starts, that is in environment.py, in function script_basedir which gets the paths from sysconfig.get_paths, setting base and platbase variables to the virtual environment prefix. That function returns for the scripts key /my/custom/venv/path/local/bin.

Now the question is: if it uses sysconfig.get_paths to find python, shouldn't it set PATH and the symlink to python accordingly, during the initial setup?

EDIT2:
reading sysconfig.py from the OS installation, the following is written:

# backup the original posix_prefix as rpm_prefix
# RPM packages use it and we need to be able to read it even when changed
_INSTALL_SCHEMES['rpm_prefix'] = _INSTALL_SCHEMES['posix_prefix']
# Virtualenv >= 20.10.0 favors the "venv" scheme over the defaults when creating virtual environments.
# See: https://github.com/pypa/virtualenv/commit/8da79db86d8a5c74d03667a40e64ff832076445e
# See: https://bugs.python.org/issue45413
# "venv" should be the same as the unpatched posix_prefix for us,
# so new virtual environments aren't created with paths like venv/local/bin/python.
_INSTALL_SCHEMES['venv'] = _INSTALL_SCHEMES['posix_prefix']

Thus in pipenv's environment.py file, script_basedir function, if I overwrite the install_scheme as follows:

install_scheme = "nt" if (os.name == "nt") else "venv" # "venv" instad of "posix_prefix"

the path is now correct again.

The problem seems to be fixed now. I wonder if this is the default Python behavior, of if it's some kind of Fedora 36 customization?

EDIT3:
and I'm still unsure whether the EDIT2 sysconfig.py code is a custom Fedora add-in, but I found this issue on the CPython github: python/cpython#89576

The text was updated successfully, but these errors were encountered:

undefx · 2022-05-24T02:21:08Z

same here. many thanks @elegos for your detailed workaround. it works for me also.

system info:

$ cat /etc/redhat-release 
Fedora release 36 (Thirty Six)

$ pip --version
pip 21.3.1 from /usr/lib/python3.10/site-packages/pip (python 3.10)

$ pipenv --version
pipenv, version 2022.4.8

$ python --version
Python 3.10.4

$ which python
/usr/bin/python

sample of original failure:

$ pipenv --rm
Removing virtualenv (/home/username/.local/share/virtualenvs/sample-_RaNdOm)...

$ pipenv install
Creating a virtualenv for this project...
Pipfile: /home/username/path/Pipfile
Using /usr/bin/python (3.10.4) to create virtualenv...
⠼ Creating virtual environment...created virtual environment CPython3.10.4.final.0-64 in 194ms
  creator CPython3Posix(dest=/home/username/.local/share/virtualenvs/sample-__RaNdOm, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/username/.local/share/virtualenv)
    added seed packages: pip==22.0.4, setuptools==62.1.0, wheel==0.37.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment! 
Traceback (most recent call last):
  File "/usr/local/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/home/username/.local/lib/python3.10/site-packages/pipenv/vendor/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)

[... snip ...]

FileNotFoundError: [Errno 2] No such file or directory: '/home/username/.local/share/virtualenvs/sample-_RaNdOm/local/bin/python'

distilled @elegos workaround:

# find pipenv install location
$ python3 -c 'import os; import pipenv as p; print(os.path.split(p.__file__)[0])'
/home/username/.local/lib/python3.10/site-packages/pipenv

# locate file `environment.py` under path above
$ find /home/username/.local/lib/python3.10/site-packages/pipenv | grep -v vendor | grep environment.py
/home/username/.local/lib/python3.10/site-packages/pipenv/environment.py

# replace 'posix_prefix' with 'venv' in file above
$ sed -i 's/posix_prefix"/venv"  # was posix_prefix, not venv/g' /home/username/.local/lib/python3.10/site-packages/pipenv/environment.py

# verify that it works
$ pipenv check
Creating a virtualenv for this project...
Pipfile: /home/username/path/Pipfile
Using /usr/bin/python (3.10.4) to create virtualenv...
⠴ Creating virtual environment...created virtual environment CPython3.10.4.final.0-64 in 307ms
  creator CPython3Posix(dest=/home/username/.local/share/virtualenvs/sample-_RaNdOm, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/username/.local/share/virtualenv)
    added seed packages: pip==22.0.4, setuptools==62.1.0, wheel==0.37.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment! 
Virtualenv location: /home/username/.local/share/virtualenvs/sample-_RaNdOm
Creating a Pipfile for this project...
Checking PEP 508 requirements...
Passed!
Checking installed package safety...
All good!

edit: formatting

g9h0 · 2022-05-24T10:32:10Z

Thank you for the workaround @elegos - This resolved the same issue on my system, which occurred after recently applying Fedora updates.

$ cat /etc/fedora-release 
Fedora release 36 (Thirty Six)

$ pip --version
pip 22.1 from /home/gareth/.local/lib/python3.10/site-packages/pip (python 3.10)

$ pipenv --version
pipenv, version 2022.5.2

$python --version
Python 3.10.4

$ which python
/usr/bin/python

RonaldTheodoro · 2022-05-24T15:14:10Z

Thanks @elegos the workaround also worked for me, this problem started after I update to fedora 36.

$ cat /etc/fedora-release 
Fedora release 36 (Thirty Six)
$ pip --version
pip 22.1 from /home/ronaldtheodoro/.local/lib/python3.10/site-packages/pip (python 3.10)
$ pipenv --version
pipenv, version 2022.5.2
$ python --version
Python 3.10.4
$ which python
/usr/bin/python

matteius · 2022-05-25T14:02:51Z

@RonaldTheodoro @garethheath @undefx and @elegos -- Do you think this PR would fix the issue and eliminate the need for the workaround? #5096

elegos · 2022-05-25T14:07:38Z

Hello @matteius yes, it should exactly do the trick we need :)

torsava · 2022-05-26T08:21:27Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

mattiasb · 2022-05-31T09:41:26Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

jguiditta · 2022-05-31T18:55:37Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

+1 We use this in CI, so if this is not going into an F36 rpm update (or at least a pypi update) soon, we will have to implement a workaround in CI, which I would prefer not to do if we can help it.

matteius · 2022-05-31T19:09:00Z

FWIW it has been merged into master branch of pipenv and I plan to do a pipenv release at some point soon, like say in the first week of June, probably. Trying to see what else we can get into that release that would be fixing an issue as well.

torsava · 2022-05-31T22:01:01Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

We have an older version of pipenv packaged in F36 which according to my testing does not suffer from this issue. I suspect you're using a newer version of pipenv installed from PyPI and thus getting the error, am I correct? If so, a new release of pipenv will fix that.

mattiasb · 2022-05-31T22:43:27Z

I uninstalled pipenv from pypi using pip3 uninstall pipenv and then made sure (via which pipenv) that I was using the correct version. At least I believe I did. Will spawn a new VM to test now.

EDIT: You are correct, I probably still had a pipenv leftover somehow in my VM at work.

jguiditta · 2022-06-01T12:34:42Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

We have an older version of pipenv packaged in F36 which according to my testing does not suffer from this issue. I suspect you're using a newer version of pipenv installed from PyPI and thus getting the error, am I correct? If so, a new release of pipenv will fix that.

The version in F36 is 2021.5.29, which is vulnerable to this CVE, so we are in an awkward position until a new release (at least to pypi, ideally also to F36) - either use a version with a known CVE, or have a broken version - the rawhide rpm in CI is not really something we can use, for multiple reason.

torsava · 2022-06-01T13:22:24Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

We have an older version of pipenv packaged in F36 which according to my testing does not suffer from this issue. I suspect you're using a newer version of pipenv installed from PyPI and thus getting the error, am I correct? If so, a new release of pipenv will fix that.

The version in F36 is 2021.5.29, which is vulnerable to this CVE, so we are in an awkward position until a new release (at least to pypi, ideally also to F36) - either use a version with a known CVE, or have a broken version - the rawhide rpm in CI is not really something we can use, for multiple reason.

We have fixed this CVE in all active Fedoras (rawhide, 36-34) with a downstream patch: https://bugzilla.redhat.com/show_bug.cgi?id=2039831

jguiditta · 2022-06-01T14:00:23Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

We have an older version of pipenv packaged in F36 which according to my testing does not suffer from this issue. I suspect you're using a newer version of pipenv installed from PyPI and thus getting the error, am I correct? If so, a new release of pipenv will fix that.

The version in F36 is 2021.5.29, which is vulnerable to this CVE, so we are in an awkward position until a new release (at least to pypi, ideally also to F36) - either use a version with a known CVE, or have a broken version - the rawhide rpm in CI is not really something we can use, for multiple reason.

We have fixed this CVE in all active Fedoras (rawhide, 36-34) with a downstream patch: https://bugzilla.redhat.com/show_bug.cgi?id=2039831

Perhaps we are doing something wrong then? We are running 'pipenv check -v', and it still reports this CVE, using the rpm version referenced above.

torsava · 2022-06-01T14:40:31Z

Hi @elegos , I've already deployed the fix for this (#5096) in Fedora rawhide and we're testing it there. The RPM might be installable on F36 too if you'd like to help us test it: https://koji.fedoraproject.org/koji/buildinfo?buildID=1965245

Do you expect this to land in F36 later on? (It's one of the issues holding me back from upgrading currently. :)).

We have an older version of pipenv packaged in F36 which according to my testing does not suffer from this issue. I suspect you're using a newer version of pipenv installed from PyPI and thus getting the error, am I correct? If so, a new release of pipenv will fix that.

The version in F36 is 2021.5.29, which is vulnerable to this CVE, so we are in an awkward position until a new release (at least to pypi, ideally also to F36) - either use a version with a known CVE, or have a broken version - the rawhide rpm in CI is not really something we can use, for multiple reason.

We have fixed this CVE in all active Fedoras (rawhide, 36-34) with a downstream patch: https://bugzilla.redhat.com/show_bug.cgi?id=2039831

Perhaps we are doing something wrong then? We are running 'pipenv check -v', and it still reports this CVE, using the rpm version referenced above.

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv), but isn't actually running the reproducer for the CVE. Can you try the reproducer directly?

jguiditta · 2022-06-01T14:57:40Z

Perhaps we are doing something wrong then? We are running 'pipenv check -v', and it still reports this CVE, using the rpm version referenced above.

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv), but isn't actually running the reproducer for the CVE. Can you try the reproducer directly?

I would be happy to, but looking at the CVE, I don't see a reproducer to try, am I looking in the wrong place? If it is helpful, I see the portion of pipenv check -v that fails is this:

Running command: $ /root/.local/share/virtualenvs/src-V0gSSv56/bin/python /usr/lib/python3.10/site-packages/pipenv/patched/safety check --json

matteius · 2022-06-01T15:04:45Z

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv).

Yes I believe that is correct. What version of pipenev are you reporting on @jguiditta pipenv --version? I just read the code and I don't see where pipenv check will check pipenv specifically -- do you possibly have a different version of pipenv installed into your project virtualenv where it is thus finding pipenv and running a check on it?

torsava · 2022-06-01T15:09:43Z

Perhaps we are doing something wrong then? We are running 'pipenv check -v', and it still reports this CVE, using the rpm version referenced above.

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv), but isn't actually running the reproducer for the CVE. Can you try the reproducer directly?

I would be happy to, but looking at the CVE, I don't see a reproducer to try, am I looking in the wrong place? If it is helpful, I see the portion of pipenv check -v that fails is this:
Running command: $ /root/.local/share/virtualenvs/src-V0gSSv56/bin/python /usr/lib/python3.10/site-packages/pipenv/patched/safety check --json

The reproducer is in the pipenv test suite, here: https://github.com/pypa/pipenv/pull/4899/files#diff-a28b281ee0902c932527e269c585ac109bdd98aa5ceebe05ca97a10a5a432651

We've backported the fix and the tests and all of them pass on the Fedora, so we believe the CVE to be fixed on all Fedoras.

jguiditta · 2022-06-01T17:03:07Z

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv).

Yes I believe that is correct. What version of pipenev are you reporting on @jguiditta pipenv --version? I just read the code and I don't see where pipenv check will check pipenv specifically -- do you possibly have a different version of pipenv installed into your project virtualenv where it is thus finding pipenv and running a check on it?

I'll make some adjustments to our job and see what else I can find out, including the answer to your question on version, though it should be the one matching the rpm mentioned earlier in this discussion. I don't see how there would be a prexisting pipenv in the virtualenv, since this is a fresh container created in CI each time, but I will do some more poking. @torsava thank you for the reproducer, I will incorporate that in my tests as well, and hopefully have some more useful information tomorrow. Thank you both for the replies!

jguiditta · 2022-06-02T15:17:06Z

Hmmm, I'm not really sure about that. My guess would be pipenv check is just checking some predefined markers (maybe just the version of pipenv).

Yes I believe that is correct. What version of pipenev are you reporting on @jguiditta pipenv --version? I just read the code and I don't see where pipenv check will check pipenv specifically -- do you possibly have a different version of pipenv installed into your project virtualenv where it is thus finding pipenv and running a check on it?

I'll make some adjustments to our job and see what else I can find out, including the answer to your question on version, though it should be the one matching the rpm mentioned earlier in this discussion. I don't see how there would be a prexisting pipenv in the virtualenv, since this is a fresh container created in CI each time, but I will do some more poking. @torsava thank you for the reproducer, I will incorporate that in my tests as well, and hopefully have some more useful information tomorrow. Thank you both for the replies!

OK, bit of a follow-up. The net is that I think using pipenv to check for CVEs will not work as expected with a distro-installed version of pipenv that has backported fixes. I did a bit of testing, making sure I ONLY had the pipenv from fedora 36 installed. I did check the above questions first, and there is indeed NO pipenv installed into the project (it is only used TO install the project). Second, version:

$ pipenv --version
pipenv, version 2021.5.29

$ rpm -qa |grep pipenv
pipenv-2021.5.29-7.fc36.noarch

$ pip show pipenv
Name: pipenv
Version: 2021.5.29
Summary: Python Development Workflow for Humans.
Home-page: https://github.com/pypa/pipenv
Author: Pipenv maintainer team
Author-email: distutils-sig@python.org
License: MIT
Location: /usr/lib/python3.10/site-packages
Requires: certifi, pip, setuptools, virtualenv, virtualenv-clone
Required-by:

The new bit is, on re-reading the pipenv --help output, I noticed it uses pyup to check for CVE, not any local information, aside from matching version in the Pipfile:

Commands:
  check      Checks for PyUp Safety security vulnerabilities and against PEP
             508 markers provided in Pipfile.

Since pyup is likely not looking at distro-specific backports, this is likely why, even though we have the CVE fix in fedora 36, the check thinks we do not. I think the net is, it we want to use 'pipenv check', we need to use a version of pipenv for a pip install to get reliable results. If that is off the rails, let me know. Otherwise, thank you for your responses/help, and I will look forward to the next release on pypi.

matteius · 2022-06-04T07:34:49Z

@jguiditta I don't quite understand -- We haven't fixed a CVE in recent releases so whatever was backported was a fix from a while ago -- if PyUp is saying there is an issue with 2021.5.29 well that is possible because its old, but if you ran with the most recent pipenv already in pypi, then I don't expect a new release to fix it since we haven't merged in any related PRs. Can you provide any more details? Why is the fedora version so old and having things backported to it?

kissifrot · 2022-06-06T09:16:08Z

However for an Ubuntu 22.04 environment (same python 3.10.x version) @elegos 's workaround does not work :(

matteius · 2022-06-06T09:38:59Z

@kissifrot did you try the main branch of pipenv? The fix hasn't been released to pypi yet, but it would be good if someone could verify the main branch fixes this issue ahead of a new release.

mattiasb · 2022-06-06T10:34:12Z

@kissifrot did you try the main branch of pipenv? The fix hasn't been released to pypi yet, but it would be good if someone could verify the main branch fixes this issue ahead of a new release.

I'll try pipenv git tonight or tomorrow on F36.

jguiditta · 2022-06-06T11:07:59Z

@jguiditta I don't quite understand -- We haven't fixed a CVE in recent releases so whatever was backported was a fix from a while ago -- if PyUp is saying there is an issue with 2021.5.29 well that is possible because its old, but if you ran with the most recent pipenv already in pypi, then I don't expect a new release to fix it since we haven't merged in any related PRs. Can you provide any more details? Why is the fedora version so old and having things backported to it?

I am not sure why we can't get the new version(s) in released fedora, but if you look at the list of builds for the package [here]https://koji.fedoraproject.org/koji/packageinfo?packageID=27010l), you can see that is the newest version, aside from rawhide, which is for testing, and not viable for our CI environment. I understand that the release pipenv shows does not contain the cve fix in question, though the fix was backported (again, not sure on reason in this case, it may just be some rules fedora gas around how much you can update a package in a given release). What I was trying to point out was that I now understand why pipenv check fails, even though the fix has been backported (because it is checking pyup against the stated version, which obviously did not contain the fix). Ideally, we would just get new releases in the fedora package management system that match upstream, but the release process there may just not allow it.

Also, to clarify, running from pypi is a viable alternative (though it would be nice to be able to use the dnf version), we will just need to wait until the current issue in this thread is released, as building from source in CI is not really something we can do.

mbothorel · 2022-06-07T09:35:57Z

@matteius I had the bug on Fedora 36, the @elegos 's workaround worked.
I tried again today with pipenv from the main branch. It worked well too. Thank you!

matteius · 2022-06-07T13:49:04Z

Thanks @mbothorel -- I am going to try to get a release out today then.

matteius · 2022-06-07T14:20:41Z

2022.6.7 has been released.

mbothorel · 2022-06-07T15:01:26Z

@matteius Thank you very much!

mattiasb · 2022-06-08T15:01:19Z

I didn't find the time to test. Sorry about that. Regardless, I tested the released version now and it works perfectly. Thanks all!

RonaldTheodoro mentioned this issue May 24, 2022

pipenv create virtual env error #5101

Closed

matteius added Type: Possible Bug This issue describes a possible bug in pipenv. Priority: High This item is high priority and should be resolved quickly. labels May 25, 2022

torsava mentioned this issue May 26, 2022

Make pipenv work with the venv install scheme if it is detected #5096

Merged

2 tasks

matteius added the Status: To Be Released label May 31, 2022

g-vidal mentioned this issue Jun 2, 2022

pipenv works with --python 3.9 fails with 3.10 (error message like #5109) #5116

Closed

matteius closed this as completed Jun 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pipenv searches virtual environment's python binary in wrong path #5109

Pipenv searches virtual environment's python binary in wrong path #5109

elegos commented May 22, 2022 •

edited

Loading

undefx commented May 24, 2022 •

edited

Loading

g9h0 commented May 24, 2022

RonaldTheodoro commented May 24, 2022

matteius commented May 25, 2022

elegos commented May 25, 2022

torsava commented May 26, 2022

mattiasb commented May 31, 2022 •

edited

Loading

jguiditta commented May 31, 2022

matteius commented May 31, 2022

torsava commented May 31, 2022

mattiasb commented May 31, 2022 •

edited

Loading

jguiditta commented Jun 1, 2022

torsava commented Jun 1, 2022 •

edited

Loading

jguiditta commented Jun 1, 2022

torsava commented Jun 1, 2022

jguiditta commented Jun 1, 2022

matteius commented Jun 1, 2022

torsava commented Jun 1, 2022

jguiditta commented Jun 1, 2022

jguiditta commented Jun 2, 2022

matteius commented Jun 4, 2022 •

edited

Loading

kissifrot commented Jun 6, 2022

matteius commented Jun 6, 2022

mattiasb commented Jun 6, 2022

jguiditta commented Jun 6, 2022

mbothorel commented Jun 7, 2022

matteius commented Jun 7, 2022

matteius commented Jun 7, 2022

mbothorel commented Jun 7, 2022

mattiasb commented Jun 8, 2022

Pipenv searches virtual environment's python binary in wrong path #5109

Pipenv searches virtual environment's python binary in wrong path #5109

Comments

elegos commented May 22, 2022 • edited Loading

undefx commented May 24, 2022 • edited Loading

g9h0 commented May 24, 2022

RonaldTheodoro commented May 24, 2022

matteius commented May 25, 2022

elegos commented May 25, 2022

torsava commented May 26, 2022

mattiasb commented May 31, 2022 • edited Loading

jguiditta commented May 31, 2022

matteius commented May 31, 2022

torsava commented May 31, 2022

mattiasb commented May 31, 2022 • edited Loading

jguiditta commented Jun 1, 2022

torsava commented Jun 1, 2022 • edited Loading

jguiditta commented Jun 1, 2022

torsava commented Jun 1, 2022

jguiditta commented Jun 1, 2022

matteius commented Jun 1, 2022

torsava commented Jun 1, 2022

jguiditta commented Jun 1, 2022

jguiditta commented Jun 2, 2022

matteius commented Jun 4, 2022 • edited Loading

kissifrot commented Jun 6, 2022

matteius commented Jun 6, 2022

mattiasb commented Jun 6, 2022

jguiditta commented Jun 6, 2022

mbothorel commented Jun 7, 2022

matteius commented Jun 7, 2022

matteius commented Jun 7, 2022

mbothorel commented Jun 7, 2022

mattiasb commented Jun 8, 2022

elegos commented May 22, 2022 •

edited

Loading

undefx commented May 24, 2022 •

edited

Loading

mattiasb commented May 31, 2022 •

edited

Loading

mattiasb commented May 31, 2022 •

edited

Loading

torsava commented Jun 1, 2022 •

edited

Loading

matteius commented Jun 4, 2022 •

edited

Loading