Питон в коробке – venv в python 3.3

[xobb1t]

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

с virtualenv это тоже работает :)

[Nikita]

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

Удивительно, сколько пользуюсь virtualenv, а узнал об этом только сейчас при выходе venv.
Сейчас внесу коррективы, спасибо.

[icCE]

Скажите, а есть информация по virtualenv на русском?
Честно признаюсь, не искал, но может есть пару закладок?

[loststylus]

Ну вот например, правда тут больше про virtualenv-wrapper – is.gd/4Wo4Ht

[icCE]

спс.

[icCE]

Кстати, а вы случайно не сравнивали скорость работы между uwsgi и gunicorn?
Не могу определится, что мне начать использовать, и то и другое в настройках не очень сложны.
Тестов в сети мало, или они сильно устаревшие.

[Nikita]

попробуйте использовать для начала эту статью, но с учётом того, что она 2-х летней давности:
nichol.as/benchmark-of-python-web-servers

[icCE]

Спс Почитаю.

[loststylus]

Нет, не сравнивал. Честно говоря, даже gunicorn'ом не довелось пользоваться.

[icCE]

А чем пользуетесь, если не секрет?

[loststylus]

uwsgi, отдаю nginx'ом.

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

[icCE]

ну с fastcgi я то же игрался, думаю огда тоже остановится на uwsgi.

Хотя конечно gunicor+gunicron console = радуют :)

[svetlov]

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

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

[Nikita]

Отлично.

Всё замечание в статью.

[Oronro]

А что на счет возможностей virtualenvwrapper? Он, как я полагаю, не совместим с venv? Какие альтернативы?

[svetlov]

Не совместим, но Даг обещал запилить вскорости.

[ZZZ_Sochi]

Сначала я тоже радовался появлению venv, но теперь, когда есть pythonbrew, я не вижу в нём особого смысла. И virtualenvwrapper, как мне кажется, тоже потерял его.

[svetlov]

А зачем эта поделка? Для тех страдальцев, которые вынуждены использовать MacOS X?

[ZZZ_Sochi]

Это чем virtualenvwrapper является меньшей поделкой, чем virtualenvwrapper?

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

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

P.S. virtualenvwrapper прекрасно работает в MacOS X. :-)

[svetlov]

Понял. Спасибо.

[Nikita]

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

Наверное можно и через HomeBrew или pythonbrew ставить, но пока это не пробовал.

[ZZZ_Sochi]

Я не использую MacPorts. Вообще не держу на рабочей машине ничего, что не собирается в виртуальное окружение.
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.

[icCE]

HomeBrew все же, «чище» — ничего лишнего не тащит в систему.

[webhamster]

В virtualenv для них достаточно было указать интерпретатор через #/usr/bin/env python3

Восклицательный знак потерялся.