Комментарии 24
А можно и не использовать, достаточно лишь вызвать интерпретатор из окружения и всё сработает автоматически:
/path/to/new/venv/bin/python3 some_script.py
с virtualenv это тоже работает :)
Ох. Действительно работает. Проверил на py 2.7 в обычном virtualenv.
Удивительно, сколько пользуюсь virtualenv, а узнал об этом только сейчас при выходе venv.
Сейчас внесу коррективы, спасибо.
Удивительно, сколько пользуюсь virtualenv, а узнал об этом только сейчас при выходе venv.
Сейчас внесу коррективы, спасибо.
Скажите, а есть информация по virtualenv на русском?
Честно признаюсь, не искал, но может есть пару закладок?
Честно признаюсь, не искал, но может есть пару закладок?
Ну вот например, правда тут больше про virtualenv-wrapper – is.gd/4Wo4Ht
спс.
Кстати, а вы случайно не сравнивали скорость работы между uwsgi и gunicorn?
Не могу определится, что мне начать использовать, и то и другое в настройках не очень сложны.
Тестов в сети мало, или они сильно устаревшие.
Не могу определится, что мне начать использовать, и то и другое в настройках не очень сложны.
Тестов в сети мало, или они сильно устаревшие.
попробуйте использовать для начала эту статью, но с учётом того, что она 2-х летней давности:
nichol.as/benchmark-of-python-web-servers
nichol.as/benchmark-of-python-web-servers
Нет, не сравнивал. Честно говоря, даже gunicorn'ом не довелось пользоваться.
> В отличии от virtualenv новый venv требует чтобы создаваемая директория не существовала, либо была пустой. Вероятно, это сделано, что бы не допускать конфликтов с существующими файлами.
Это уже починено в default branch, выйдет в 3.4
Это уже починено в 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. :-)
Вот у меня на сервере 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 ставить, но пока это не пробовал.
Наверное можно и через HomeBrew или pythonbrew ставить, но пока это не пробовал.
Я не использую MacPorts. Вообще не держу на рабочей машине ничего, что не собирается в виртуальное окружение.
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.
HomeBrew все же, «чище» — ничего лишнего не тащит в систему.
В virtualenv для них достаточно было указать интерпретатор через
#/usr/bin/env python3
Восклицательный знак потерялся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Питон в коробке – venv в python 3.3