pypa/virtualenv

chat discussion about the pypa virtualenv

nekokatt

@nekokatt

the latter would use virtualenv to make a venv (works on 20.0.18), and then activates it and runs something like pip install pytest in it

https://www.github.com/theacodes/nox/tree/master/nox%2Fvirtualenv.py L394 suggests this simply invokes python -m venv {{name here}}.

nekokatt

@nekokatt

I'd have posted an issue with nox on their issue tracker but from appearences this appears to be something triggered by whatever changed from 20.0.18 to 20.0.19, so I started here with a hope of working backwards :)

Line 354*

Bernát Gábor

@gaborbernat

I'd like to have a reproducible that breaks down the error to outside of nox

or raise the issue for nox

Donald Stufft

@dstufft

I don't think I can quite understand with a quick skim-- does virtualenv install the latest pip by default still or has it regressed that behavior back to only installing the bundled version?

That switch feels super user hostile now :/

Bernát Gábor

@gaborbernat

We've had a long discussion on the issue about this. I don't think it's user hostile at all, on the contrary.

Nicolai Waniek

@rochus

Hi! I'm currently trying to hunt down the issue for the following: I want to replace blender's shipped python version with a local install for several reasons. With virtualenv 15.1.0 (default on Ubuntu 18.04) this is no problem at all, you can simply point blender via symlink to a virtualenv's python. Using virtualenv 20.0.20, however, this won't work an blender will quit with an ImportError about encodings (and possibly several other, it's just the first one before it quits). I had a look at the virtualenv file tree created with either virtualenv version and now try to understand the changes between before and after its rewrite. In particular, virtualenv 15.1.0 (and 16 for that matter) copies/symlinks several files, such as encodings, collections, lib-dynload, etc. which are specified in the "old" virtualenv.py in variables REQUIRED_MODULES and REQUIRED_FILES. I did not find this behavior in the source of virtualenv 20.0.20. Is this intended behavior? If yes, what would be the right way to have these files importable?

Bernát Gábor

@gaborbernat

the site.py should correctly rewrite the sys.path to make them importable

see https://github.com/pypa/virtualenv/blob/master/src/virtualenv/create/via_global_ref/builtin/python2/site.py#L80-L100 for more details

please provide more information or see why that rewrite fails

do you have a docker image to replicate this?

or some steps that is; if so open an issue, well might be that blender python is not supported in the current form by virtualenv 20

see https://virtualenv.pypa.io/en/latest/installation.html#python-and-os-compatibility on what we target

Nicolai Waniek

@rochus

Thanks for your reply. I don't yet have a docker image, but it only requires a handful of steps. I'll check the links you provided and open an issue if it doesn't answer or solve the issue.

Jason Pickens

@steinybot

Is it possible to have virtual env create a link for python3.6 to python just like it does for python3?

This is to workaround/fix pyenv/pyenv#1275

Bernát Gábor

@gaborbernat

this should be the case with virutalenv 20 @steinybot; isn't it??

Jason Pickens

@steinybot

Ah it seems you are right, maybe I had an older virtualenv version.

Bernát Gábor

@gaborbernat

cool

Jason Pickens

@steinybot

Uh wait maybe not. I think it is a venv problem anyway.

Harry Mallon

@hjmallon

Hi there, I'm not a Python expert but I use virtualenv through a C++ package manager called hunter which can install certain pip libs into a venv. See https://github.com/cpp-pm/hunter_venv/blob/master/CMakeLists.txt. Hunter's use of virtualenv includes the removed '--relocatable' flag so we can't use v20 at the moment. We are also trying to support CentOS7 but a fix for Fedora/CentOS was only just put into v20 recently. Does anyone have an idea how to replace the use of --relocatable in Hunter?

Bernát Gábor

@gaborbernat

Why does hunter requires relocatable? I'm not aware of any relocatable alternative implementations

Harry Mallon

@hjmallon

To be honest I'm not 100% sure why it uses it. I would have to dig into thw history of it a bit more.

That's a shame that there aren't any recommended relocation alternatives. Perhaps hunter can be reworked not to need it.

Bernát Gábor

@gaborbernat

You'll need to pick up that with the hunter developers. or pin to use old virtualenv

Harry Mallon

@hjmallon

Thanks Bernát

Miguel Alberto Plazas

@ambigus9

Hi, Currently i'm trying to create a virtual enviroment as follows: virtualenv --python=python3.7

However, i'm getting this error:

RuntimeError: failed to find interpreter for Builtin discover of python_spec='python3.6'

Maybe that error is because i have installed python 3.8?

Bernát Gábor

@gaborbernat

Shouldn't be

Though to tell more we need the log with -vvv

Miguel Alberto Plazas

@ambigus9

Sure @gaborbernat

107 get PythonInfo from /home/miguel/.local/share/virtualenv/py_info/20.0.20/e7370f93d1d0cde622a1f8e1c04877d8463912d04d973331ad4851f04de6915a.json for /bin/python [DEBUG cached_py_info:79]
107 Attempting to release lock 139722758691856 on /home/miguel/.local/share/virtualenv/py_info/20.0.20/e7370f93d1d0cde622a1f8e1c04877d8463912d04d973331ad4851f04de6915a.lock [DEBUG filelock:315]
108 Lock 139722758691856 released on /home/miguel/.local/share/virtualenv/py_info/20.0.20/e7370f93d1d0cde622a1f8e1c04877d8463912d04d973331ad4851f04de6915a.lock [INFO filelock:318]
108 proposed PathPythonInfo(spec=CPython2.7.18.candidate.1-64, exe=/bin/python, platform=linux2, version='2.7.18rc1 (default, Apr  7 2020, 12:05:55) \n[GCC 9.3.0]', encoding_fs_io=UTF-8-None) [INFO builtin:50]
108 discover PATH[7]=/usr/games [DEBUG builtin:84]
108 discover PATH[8]=/usr/local/games [DEBUG builtin:84]
109 discover PATH[9]=/snap/bin [DEBUG builtin:84]
109 RuntimeError: failed to find interpreter for Builtin discover of python_spec='python3.7' [ERROR __main__:57]

Bernát Gábor

@gaborbernat

The error you first posted and this do not match up

Kruno

@TDKZG

Hi to all. I have installed 2 venv's just for testing. First one is: 'HelloWorld1': pipenv and 2nd: 'HelloWorld2: venv'

Question is: How can I delete/uninstall the second one? Can you do it with only one command in terminal or I have to manually delete virtualenvs folders in Windows? I'm using Python 3.7.7 + VS Code

Bernát Gábor

@gaborbernat

sorry venv is not virtualenv

Sorin Sbarnea

@ssbarnea

@gaborbernat can you please help me double check something regarding future of venv?

while pyenv is planned for removal, the python3 -m venv there to stay.

no other reasons for not using venv for those that do not need to support py27

Bernát Gábor

@gaborbernat

@ssbarnea not sure I understand

tools will use virtualenv as offers better API

end-users might still be interested in using virtualenv over venv due to virtualenv being faster and fixes bugs faster

plus offers some features (e.g. automatic .gitignore within a venv) and such

https://virtualenv.pypa.io/en/latest/ details this

IMHO if installing virtualenv is not painful (or if you don't run in some awkward bug using it) it's better over venv

dboeckenhoff

@dboeckenhoff

Hey people. When running my tests with tox in a virtualenv I run into ImportMismatchError, e.g.: ImportMismatchError: ('tfields.main', '/builds/dboe/tfields/.tox/py37/lib/python3.7/site-packages/tfields/main.py', local('/builds/dboe/tfields/tfields/main.py'). Any hints? I keep coming back to https://stackoverflow.com/questions/44067609/getting-error-importmismatcherror-while-running-py-test but am not sure a) if that is my problem and b) how to remove __pycache__ within tox environments

see https://gitlab.mpcdf.mpg.de/dboe/tfields/-/jobs/1121415 for the failing example. It seems like python is confusing the local import with a 3rd party import

Bernát Gábor

@gaborbernat

I don't think this is virtualenv related, but python in general

Where communities thrive

People

Repo info

Activity