Пытаюсь, наконец, перейти на Python 3, но у меня возникают некоторые проблемы с virtualenvwrapper. Я начинаю с создания виртуальной среды следующим образом:
mkvirtualenv -p /usr/local/bin/python3 projectname
который дает:
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python3/3.3.3/Frameworks/Python.framework/Versions/3.3'
New python executable in projectname/bin/python3.3
Also creating executable in projectname/bin/python
Installing setuptools, pip...done.
Все идет нормально. Я проверяю консоль Python, чтобы убедиться, что среда смотрит на правильный интерпретатор и все такое, и это так. Вот где происходит печаль (пока виртуалка активна):
pip install flask претендует на успех, но увы:
Python 3.3.3 (default, Jan 2 2014, 13:26:32)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import flask
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named 'flask'
Вот проблема:
$ pip show flask
---
Name: Flask
Version: 0.10.1
Location: /usr/local/lib/python3.3/site-packages
Requires: Werkzeug, Jinja2, itsdangerous
Если я полностью не понимаю virtualenv/wrapper и их соответствующую магию (что вполне может быть), похоже, что pip install устанавливает Flask глобально, а не на сайт-пакеты в моем virtualenv, и, таким образом, virtualenv игнорирует это.
Любые подсказки, что здесь происходит / как исправить? Я ошибаюсь, предполагая, что virtualenvwrapper готов к работе в прайм-тайм с python3? Предпочтительны красивые решения, в которых мне не нужно калечить мой .bashrc или вручную устанавливать переменные среды. Я надеюсь, что есть способ сделать это с помощью API, предоставляемого virtualenv и virtualenvwrapper.
Спасибо!
pipиvirtualenv? (Или вы используетеvenvвместоvirtualenv?) Я помню некоторую проблему с pip 1.4 и последними версиями virtualenv (хотя эти версии поставлялись с 1.4), которая была решена путем обновления до pip 1.5, но я не могу вспомнить, было ли это проблема… - person abarnert schedule 06.01.2014virtualenv --version, я получаю 1.11 - person follyroof schedule 06.01.2014pip, а неpipвашей виртуальной среды, что, как я ожидаю, вызовет именно эту проблему.which pipпоказывает /usr/local/bin/pip или это правильный путь (тот, что внутри вашей среды)? - person abarnert schedule 06.01.2014pipдо тех пор, пока вы передаете -E илиexport PIP_RESPECT_VIRTUALENV=true. Вам также может понадобитьсяexport PIP_VIRTUALENV_BASE=$WORKON_HOME. - person abarnert schedule 06.01.2014which pipговорит ~/.virtualenvs/spelling/bin/pip. это кажется правильным. хотя системный пункт выглядит как версия 1.3 ... может быть, устаревшая версия делает что-то странное, поскольку настраивает virtualenv? - person follyroof schedule 06.01.2014pipдо версии 1.5, а затем запустить новую оболочку, активировать venv и посмотреть, работает ли она. - person abarnert schedule 06.01.2014virtualenvwrapper, — это более старый Python 3.2/pip 1.3, и он использует python.org Python вместо Homebrew. Если у меня будет шанс, я настрою его на другой своей машине и посмотрю, смогу ли я воспроизвести/отладить вашу проблему. Но, надеюсь, кто-то еще придет и поможет вам до этого. - person abarnert schedule 06.01.2014which pipговорит, что использует один, установленный в virtualenv, когда я делаюpip --version, он говорит, что pip 1.5 из /usr/local/lib/python3.3/site-packages, поэтому я думаю, что он действительно использует системный pip-3.3, несмотря на вводящий в заблуждение выводwhich pip.. Есть ли простое исправление, позволяющее вместо этого использовать локальный pip, если это дело? - person follyroof schedule 07.01.2014pip(cat $(which pip)), вы увидите, что (а) это скрипт Python, поэтому, если #! строка неверна, вы запустите неправильный интерпретатор, и (б) это тривиальный скрипт, который просто импортирует и запускает некоторый код из установленного модуля, поэтому, если он импортирует неправильныйsys.path, вы получите неправильныйpipкод. Я не знаю, что из этих двух не работает для вас, или почему, или как это исправить, но это может помочь вам понять, где копать дальше. - person abarnert schedule 07.01.2014pip --versionподразумевает, что он копирует файл pip-3.3 из /usr/local/lib/python3.3/site-packages. может быть, он копирует его буквально, не меняя строку интерпретатора? Интересно, это ошибка в pip-1.5-py3.3 или virtualenv или что-то в этом роде... - person follyroof schedule 07.01.2014pipбудет использовать что-то вроде#!/usr/bin/env python3, что будет отлично работать, когда вы активируете virtualenv. Если вы установите двоичный файл Python 3.3 с python.org, а затем установитеpipчерезget-pip.py, вы получите это, и все будет работать нормально. Но если вы устанавливаете Python 3.3 через Homebrew (с его слегка измененной конфигурацией и предустановленнымpip), вы получите другой #!. На самом деле это не ошибка ни в пакете virtualenv, ни в пакете Homebrew, но вместе… - person abarnert schedule 07.01.2014