Virtualenv: site.py не совместим с Python 2.7

Созданный на 9 нояб. 2012  ·  24Комментарии  ·  Источник: pypa/virtualenv

Мы используем исключительно python 2.7, и сегодня с удивлением обнаруживаем, что site.py во всех виртуальных средах с python 2.7 использует site.py py2.6, в котором отсутствуют многие новые функции, добавленные в python 2.7.

Самый полезный комментарий

В качестве обходного пути: python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())" удается найти расположение моего каталога пакетов сайтов Python.

Все 24 Комментарий

Можете ли вы привести пример того, что не работает для вас?

site.getsitepackages() не работает.

Воспроизведено на OS X:

$ virtualenv -p python2.7 ve
$ ./ve/bin/python -c 'import site; print(getattr(site, "getsitepackages"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'getsitepackages'

У меня работает вне venv -

``` $ python -c 'import site; print(getattr(site, "getsitepackages"))' <function getsitepackages at 0x104198410>

``````

$ ./ve/bin/python -c 'импорт сайта; печать( сайт.файл )'
/private/tmp/ve/lib/python2.7/site.pyc
$ python -c 'импорт сайта; печать ( файл сайта) '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.pyc

We ship our own `./virtualenv_embedded/site.py`

Рассмотрите возможность обновления (и обеспечения обратной совместимости) site.py.

Я не думаю, что это должно быть помечено как блокировщик релиза. хотя было бы здорово поддерживать совместимые с функциями файлы site.py, этот недостаток существует уже много лет.

«Этот недостаток сохраняется годами». И да, до сих пор болит... :(
Рассмотрите возможность исправления этого плз, спасибо

Это укусило меня сегодня; было бы очень, очень приятно получить обновленный site.py , включенный в virtualenv , поскольку в старой версии 2.6 нет таких вещей, как site.getusersitepackages() .

Он укусил меня тоже, и это застало меня врасплох. Теперь мне даже интересно, чем еще файлы отличаются от системного питона (особенно при использовании --system-site-packages ) и какие еще «баги» подстерегают…

Все еще действует при использовании virtualenv 13.1.2 с Python 2.7.6, и это мешает некоторым работам разработчиков, которые я делаю.

Вот интерактивная возня:

getsitepackages отсутствует в virtualenv
$ virtualenv --version
13.1.2
$ virtualenv test
New python executable in test/bin/python
Installing setuptools, pip, wheel...done.
$ source test/bin/activate
$ which python
/home/user/test/bin/python
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> 'getsitepackages' in dir(site)
False
>>> site.getsitepackages()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'getsitepackages'
>>>
getsitepackages присутствует в системе Python
$ deactivate
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> 'getsitepackages' in dir(site)
True
>>> site.getsitepackages()
['/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages']
>>>

Редактировать: вау..... Я только что прочитал: https://github.com/pypa/virtualenv/pull/697
Я думаю, что время, вероятно, лучше потратить на устранение основных причин, а не на этот конкретный симптом. В зависимости от того, как пойдет переписывание, я более чем готов дождаться любых изменений, которые необходимо внести для решения этой проблемы, в пользу изменений, обсуждаемых в переписывании.

Оригинальный комментарий:
Меня тоже только что укусила эта штука.

# Tried with and without --system-site-packages

[username@hostname] ~/dir $ virtualenv --system-site-packages venv
Using base prefix '/usr'
New python executable in venv/bin/python3.4
Also creating executable in venv/bin/python
Installing setuptools, pip, wheel...done.
[username@hostname] ~/dir $ venv/bin/python
Python 3.4.3 (default, Jul 28 2015, 18:20:59) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.getsitepackages()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'getsitepackages'
>>> 

рассмотрите возможность обновления site.py , чтобы предоставить site.getsitepackages()

Устраните эту проблему с помощью # 555, что может привести к другому поведению в виртуальной среде, если вы запустите с -Werror из-за предупреждения об устаревании. Поскольку tox зависит от внутренней работы этого пакета, не вижу особого способа обойти его.

+1 sad_panda и много слез

+1 это меня сегодня укусило, код работает вне virtualenv, но не внутри.

+1 укус, есть какое-то обновление? Спасибо.

+1 такая же проблема с rk (удаленное ядро ​​для jupyter).

+1 укус, работает вне virtualenv, но не внутри.

Все, я думаю, что на данный момент лучшим решением может быть вендорство site.py (или его частей) в ваших проектах.

В качестве обходного пути: python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())" удается найти расположение моего каталога пакетов сайтов Python.

+1

+1 укус, есть какое-то обновление? Спасибо.

я использую virtualenv 15.0.1 на Ubuntu 16.04 64bit

+1 укус
(виртуальная версия 15.1.0 на CentOS 7.5.1804)

С тех пор, как я перешел на py3, я перестал использовать virtualenv и использую собственный venv python. С python 3.6+ минималистский venv состоит всего из пары символических ссылок:

$ python3.6 -m venv --without-pip grut
$ tree grut/
grut/
├── bin
│   ├── activate
│   ├── activate.csh
│   ├── activate.fish
│   ├── python -> python3.6
│   ├── python3 -> python3.6
│   └── python3.6 -> /usr/bin/python3.6
├── include
├── lib
│   └── python3.6
│       └── site-packages
├── lib64 -> lib
└── pyvenv.cfg

6 directories, 7 files

Так что для меня больше нет virtualenv и всех его причуд. HTH другие люди.

@RemiCardona Я использую venv Python 3 столько, сколько могу, но, к сожалению, tox по-прежнему использует virtualenv (даже при тестировании Python 3), поэтому я столкнулся с этой проблемой. каждый раз, когда я использую tox для автоматизации тестирования или непрерывной интеграции. 😞

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время в ней не было активности. Он будет закрыт, если никакой дальнейшей активности не произойдет. Просто добавьте комментарий, если хотите оставить его открытым. Спасибо за ваш вклад.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги