Pull to refresh

Comments 23

А можно и не использовать, достаточно лишь вызвать интерпретатор из окружения и всё сработает автоматически:
/path/to/new/venv/bin/python3 some_script.py

с virtualenv это тоже работает :)
Ох. Действительно работает. Проверил на py 2.7 в обычном virtualenv.

Удивительно, сколько пользуюсь virtualenv, а узнал об этом только сейчас при выходе venv.
Сейчас внесу коррективы, спасибо.
Скажите, а есть информация по virtualenv на русском?
Честно признаюсь, не искал, но может есть пару закладок?
Кстати, а вы случайно не сравнивали скорость работы между uwsgi и gunicorn?
Не могу определится, что мне начать использовать, и то и другое в настройках не очень сложны.
Тестов в сети мало, или они сильно устаревшие.
Нет, не сравнивал. Честно говоря, даже gunicorn'ом не довелось пользоваться.
А чем пользуетесь, если не секрет?
uwsgi, отдаю nginx'ом.

Какое-то время даже fastcgi по приколу пользовался, но этого делать не нужно :)
ну с fastcgi я то же игрался, думаю огда тоже остановится на uwsgi.

Хотя конечно gunicor+gunicron console = радуют :)
> В отличии от virtualenv новый venv требует чтобы создаваемая директория не существовала, либо была пустой. Вероятно, это сделано, что бы не допускать конфликтов с существующими файлами.

Это уже починено в default branch, выйдет в 3.4
Отлично.

Всё замечание в статью.
А что на счет возможностей virtualenvwrapper? Он, как я полагаю, не совместим с venv? Какие альтернативы?
Не совместим, но Даг обещал запилить вскорости.
Сначала я тоже радовался появлению venv, но теперь, когда есть pythonbrew, я не вижу в нём особого смысла. И virtualenvwrapper, как мне кажется, тоже потерял его.
А зачем эта поделка? Для тех страдальцев, которые вынуждены использовать MacOS X?
Это чем virtualenvwrapper является меньшей поделкой, чем virtualenvwrapper?

Вот у меня на сервере Debian Squeeze, который ничего о питоне 2.7 не знает и знать не хочет (про 3.3 даже и говорить нечего). Что делать?
С помощью pythonbrew это решается одним движением. При этом, ничего лишнего, кроме самого pythonbrew (через pip) в систему ставить не надо. Как минимум, это гигиенично, гибко и удобно — раньше я использовал для этого checkinstall и это очень сильно плохое решение.
Плюс создание окружений и переключение между ними работает так же, как и с virtualenvwrapper — одной командой.

В общем, ни одного минуса от его использования я не увидел и и пустил в продакшн.

P.S. virtualenvwrapper прекрасно работает в MacOS X. :-)
В OS X, кстати, python тоже вполне неплохо ставиться и через MacPorts. При этом можно держать несколько версий. По факту, я, например, держу 4 штуки. Даже можно менять дефолтную версию (остальные будут вызываться как pythonx.y).

Наверное можно и через HomeBrew или pythonbrew ставить, но пока это не пробовал.
Я не использую MacPorts. Вообще не держу на рабочей машине ничего, что не собирается в виртуальное окружение.
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.
HomeBrew все же, «чище» — ничего лишнего не тащит в систему.
Only those users with full accounts are able to leave comments. Log in, please.