Comments 44
> Почему выполняются эти, а не какие-либо иные действия?
Потому что эта последовательность действий приводит к описанному в примере результату.
И как и написано в самом начале — это только один из возможных вариантов, который лично для меня в текущий момент является наиболее удобным.
> Где объяснения?
Я старался описывать действия до примера вызова команды.
В целом ответить на такой вопрос довольно непросто.
Если у вас есть конкретные примеры непонятных действий — напишите, а я постараюсь написать объяснения по-другому, да побольше.
> Всю эту «статью» можно пересказать одной ссылкой на provision.sh.
Я с таким ещё не сталкивался.
Более того я не смог понять какой именно 'provision.sh' имеется в виду при поиске в google.
www.google.com.ua/search?client=ubuntu&channel=fs&q=provision.sh&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=wrTcVMjfIMuG8QfSl4G4Bg
Дайте, пожалуйста, прямую ссылку.
После «ознакомления» я смогу ответь что-то более внятное.
Потому что эта последовательность действий приводит к описанному в примере результату.
И как и написано в самом начале — это только один из возможных вариантов, который лично для меня в текущий момент является наиболее удобным.
> Где объяснения?
Я старался описывать действия до примера вызова команды.
В целом ответить на такой вопрос довольно непросто.
Если у вас есть конкретные примеры непонятных действий — напишите, а я постараюсь написать объяснения по-другому, да побольше.
> Всю эту «статью» можно пересказать одной ссылкой на provision.sh.
Я с таким ещё не сталкивался.
Более того я не смог понять какой именно 'provision.sh' имеется в виду при поиске в google.
www.google.com.ua/search?client=ubuntu&channel=fs&q=provision.sh&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=wrTcVMjfIMuG8QfSl4G4Bg
Дайте, пожалуйста, прямую ссылку.
После «ознакомления» я смогу ответь что-то более внятное.
Это намек на то, что стоило бы освоить Vagrant
> Это намек на то, что стоило бы освоить Vagrant
Vagrant освоен и используется ежедневно.
Но для меня он не пересекается с темой примера.
Данный пример показывает как запуститься на локальной машине,
а не «поднимать» виртуальную — «руками» или Vagrant'ом, не суть.
Ничто не мешает проделать подобные действия внутри «виртуалки» — «руками» или через Ansible, например.
Vagrant освоен и используется ежедневно.
Но для меня он не пересекается с темой примера.
Данный пример показывает как запуститься на локальной машине,
а не «поднимать» виртуальную — «руками» или Vagrant'ом, не суть.
Ничто не мешает проделать подобные действия внутри «виртуалки» — «руками» или через Ansible, например.
Тогда вы бы знали, что имеется в виду под provision
> Тогда вы бы знали, что имеется в виду под provision
У меня есть опыт использования 'vagrant provision' — docs.vagrantup.com/v2/cli/provision.html
Конкретнее 'Ansible Provisioner' — docs.vagrantup.com/v2/provisioning/ansible.html
А именно с 'provision.sh' я ещё не сталкивался, я уже писал об этом «выше».
У меня есть опыт использования 'vagrant provision' — docs.vagrantup.com/v2/cli/provision.html
Конкретнее 'Ansible Provisioner' — docs.vagrantup.com/v2/provisioning/ansible.html
А именно с 'provision.sh' я ещё не сталкивался, я уже писал об этом «выше».
> Перед написанием статьи надо определиться с целевой аудиторией.
> Если статья для новичков, надо описывать не только выполняемые действия, но и их значение.
> Если статья для продвинутых, то мимо, в статье элементарщина.
> Вы промахнулись мимо какой-либо ЦА.
Скорее всего сейчас у меня не хватает навыка «попадания в ЦА».
Я написал этот пример так, как бы сам хотел его видеть.
Постараюсь это учесть в следующий раз.
> Эту статью можно сократить до одного файла с инструкциями для vagrant, по которому поднимется сервер.
Да, можно.
Но данный пример показывает как запуститься на локальной машине, а не «поднимать» виртуальную.
> Руками это делать незачем.
Тут я с вами не согласен.
Лично мне сейчас нравится это делать «руками», как в примере, а не «городить виртуалки».
Возможно кому-нибудь ещё пригодится какая-нибудь часть моего примера.
> Если статья для новичков, надо описывать не только выполняемые действия, но и их значение.
> Если статья для продвинутых, то мимо, в статье элементарщина.
> Вы промахнулись мимо какой-либо ЦА.
Скорее всего сейчас у меня не хватает навыка «попадания в ЦА».
Я написал этот пример так, как бы сам хотел его видеть.
Постараюсь это учесть в следующий раз.
> Эту статью можно сократить до одного файла с инструкциями для vagrant, по которому поднимется сервер.
Да, можно.
Но данный пример показывает как запуститься на локальной машине, а не «поднимать» виртуальную.
> Руками это делать незачем.
Тут я с вами не согласен.
Лично мне сейчас нравится это делать «руками», как в примере, а не «городить виртуалки».
Возможно кому-нибудь ещё пригодится какая-нибудь часть моего примера.
> А разве есть какая-то разница в действиях при разворачивании окружения для реальной машины и виртуалки? o_O
На локальной машине (с которой сейчас открыт firefox и я набираю этот комментарий)
лично мне достаточно иметь виртуальное окружение с Python 3.4.2 «внутри».
Этого вполне хватает для моей «песочницы» и разворачивается «руками» за 10-15 минут
путём вдумчивого копирования команд из этого примера.
Причём необходимость «разворачивать» возникает далеко не каждый день.
Когда у меня будет необходимость «развернуться» на сервере или внутри виртуалки
я выделю немного времени и «заверну» всё необходимое в Ansible.
Конечно, лучше было бы сразу использовать Ansible для установки всего необходимого
и на локальную машину в том числе.
Но сейчас это не так и надобности делать иначе тоже нет.
> Офигеть, какой обоснованный довод. «Мне нравится».
Я хотел бы уточнить с чего вы взяли, что я обязан перед вами оправдываться?
Свои доводы я написал «выше», но они для вас несущественны.
Я хочу ещё раз прояснить:
> Я написал этот пример так, как бы сам хотел его видеть.
Как я понял, если мой пример всем-всем не понравится,
то я получу много-много минусов от сообщества
и не смогу больше писать свои мысли на habr.ru.
> А мне в детстве нравилось в грязной луже сидеть и ладошками по поверхности шлепать.
Рад за вас, но это никак не относится к теме моего примера.
Если вы хотите и можете помочь — напишите в комментарии «как нужно»,
тогда я поправлю пример и все будут счастливы.
На локальной машине (с которой сейчас открыт firefox и я набираю этот комментарий)
лично мне достаточно иметь виртуальное окружение с Python 3.4.2 «внутри».
Этого вполне хватает для моей «песочницы» и разворачивается «руками» за 10-15 минут
путём вдумчивого копирования команд из этого примера.
Причём необходимость «разворачивать» возникает далеко не каждый день.
Когда у меня будет необходимость «развернуться» на сервере или внутри виртуалки
я выделю немного времени и «заверну» всё необходимое в Ansible.
Конечно, лучше было бы сразу использовать Ansible для установки всего необходимого
и на локальную машину в том числе.
Но сейчас это не так и надобности делать иначе тоже нет.
> Офигеть, какой обоснованный довод. «Мне нравится».
Я хотел бы уточнить с чего вы взяли, что я обязан перед вами оправдываться?
Свои доводы я написал «выше», но они для вас несущественны.
Я хочу ещё раз прояснить:
> Я написал этот пример так, как бы сам хотел его видеть.
Как я понял, если мой пример всем-всем не понравится,
то я получу много-много минусов от сообщества
и не смогу больше писать свои мысли на habr.ru.
> А мне в детстве нравилось в грязной луже сидеть и ладошками по поверхности шлепать.
Рад за вас, но это никак не относится к теме моего примера.
Если вы хотите и можете помочь — напишите в комментарии «как нужно»,
тогда я поправлю пример и все будут счастливы.
а почему не докер?
А в чем сложность?
> А в чем сложность?
Не могу понять «контекст» вопроса.
Уточните, пожалуйста, о сложности чего именно вы бы хотели узнать?
Не могу понять «контекст» вопроса.
Уточните, пожалуйста, о сложности чего именно вы бы хотели узнать?
В чем сложность запуска Django 1.7.4 под Python 3.4.2 на Ubuntu 14.04?
> В чем сложность запуска Django 1.7.4 под Python 3.4.2 на Ubuntu 14.04?
Изначально в системе нет Python 3.4.2.
На примере показан один из возможных вариантов установки Python 3.4.2
и создания виртуального окружения с этой версией Python «внутри».
Причём данный способ может применяться не только для установки Python 3.4.2.
Вы можете выбрать любую из поддерживаемых pyenv версий Python
(список есть в примере, скрыт под spoiler).
И, проделав аналогичные примеру действия, вы можете получить
виртуальное окружение с нужной вам версией Python «внутри».
Изначально в системе нет Python 3.4.2.
На примере показан один из возможных вариантов установки Python 3.4.2
и создания виртуального окружения с этой версией Python «внутри».
Причём данный способ может применяться не только для установки Python 3.4.2.
Вы можете выбрать любую из поддерживаемых pyenv версий Python
(список есть в примере, скрыт под spoiler).
И, проделав аналогичные примеру действия, вы можете получить
виртуальное окружение с нужной вам версией Python «внутри».
Зачем этот цирк с pyenv? Ещё сегодня утром Ubuntu базировалась на Debian, а не на Slackware. Зачем игнорировать существующую бинарную дистрибуцию и предоставляемые ей инструменты, да ещё и таким извращённым образом? Всё то, что делает pyenv можно сделать без него при помощи update-alternatives и virtualenv. Собственно, там в документации неявно и написана аудитория этого проекта: «This project was forked from rbenv and ruby-build, and modified for Python».
Чем этот метод лучше всех остальных, описанных раньше?
Чем этот метод лучше всех остальных, описанных раньше?
> Зачем этот цирк с pyenv?
> Всё то, что делает pyenv можно сделать без него при помощи update-alternatives и virtualenv.
Напишите, пожалуйста, каким образом можно иметь одновременно установленные:
01. Python 2.7.6
02. Python 2.7.9
03. Python 2.5.6
04. Python 2.6.6
05. Python 3.0.1
06. Python 3.1.5
07. Python 3.3.3
08. Python 3.4.2
09. Python3.5-dev
10. jython-2.5.3
11. pypy-2.5.0
12. pypy3-2.4.0
при помощи update-alternatives.
И как обеспечить обновление Ubuntu в «штатном» режиме при таких условиях?
Я спрашиваю, т.к. моих навыков обращения с 'update-alternatives' недостаточно для решения подобной задачи,
но я бы очень хотел научиться не игнорировать, а наоборот — использовать существующую бинарную дистрибуцию
и предоставляемые ей инструменты.
Расскажите, пожалуйста, как это сделать правильно.
У меня есть подозрения, что это будет интересно узнать не только мне.
> Всё то, что делает pyenv можно сделать без него при помощи update-alternatives и virtualenv.
Напишите, пожалуйста, каким образом можно иметь одновременно установленные:
01. Python 2.7.6
02. Python 2.7.9
03. Python 2.5.6
04. Python 2.6.6
05. Python 3.0.1
06. Python 3.1.5
07. Python 3.3.3
08. Python 3.4.2
09. Python3.5-dev
10. jython-2.5.3
11. pypy-2.5.0
12. pypy3-2.4.0
при помощи update-alternatives.
И как обеспечить обновление Ubuntu в «штатном» режиме при таких условиях?
Я спрашиваю, т.к. моих навыков обращения с 'update-alternatives' недостаточно для решения подобной задачи,
но я бы очень хотел научиться не игнорировать, а наоборот — использовать существующую бинарную дистрибуцию
и предоставляемые ей инструменты.
Расскажите, пожалуйста, как это сделать правильно.
У меня есть подозрения, что это будет интересно узнать не только мне.
pyenv переключает нужную версию питона просто по файлу .pyenv-version в корне проекта. Например в нужном проекте сработает python2.7, в другом 3.4.1.
pyenv может легко поставить любую версию python, в том числе и последние свежие pypy и тому подобное.
То что его идея пришла из мира руби не делает её плохой.
Чуваки из дебиан немного странные и сломали easy_pip как-то раз, с совершенно тупой аргументацией. В итоге python -m venv пошел лесом.
Но учитывайте же, что это всё инструменты для удобной разработки — деплоить через pyenv я не рекомендую — при деплое вполне возможно воткнуть на сервер правильную версию интерпретатора с помощью какого-либо репо.
update_alternatives — ооочень странные рекомендации — нафига? В стартовом скрипте укажите полный путь до нужной версии, всё будет работать без этой фигни странной.
pyenv может легко поставить любую версию python, в том числе и последние свежие pypy и тому подобное.
То что его идея пришла из мира руби не делает её плохой.
Чуваки из дебиан немного странные и сломали easy_pip как-то раз, с совершенно тупой аргументацией. В итоге python -m venv пошел лесом.
Но учитывайте же, что это всё инструменты для удобной разработки — деплоить через pyenv я не рекомендую — при деплое вполне возможно воткнуть на сервер правильную версию интерпретатора с помощью какого-либо репо.
update_alternatives — ооочень странные рекомендации — нафига? В стартовом скрипте укажите полный путь до нужной версии, всё будет работать без этой фигни странной.
Я, видимо, не понимаю, какую нерешённую проблему решает pyenv, и от этого не могу понять, что вы мне пытаетесь донести. Может быть имеет смысл начать с этого. Манипулировать PATH для вызова нужного интерпретатора умеет virtualenv, активировать virtualenv при заходе в директорию умеет шелл (очень тривиально делается, я в это игрался, но выбросил очень быстро, у меня не прижилось). Поставить любую версию интерпретатора может пакетный менеджер. Кода для создания правил сборки пакетов в коде pyenv нет, он просто разводит банальную слаку в ~/.pyenv/versions. Для меня это так же отвратительно, как не мыть руки после посещения туалета.
Про деплой в таком виде, естественно, речи идти даже не может. Хватит того, что зачастую проект дешевле в virtualenv деплоить, чем заниматься пакетированием. При разработке — может быть, но, как я выше написал, всё, что делает pyenv уже давно делается без него и никакую нерешённую проблему я не вижу, единственное объяснение, которое я смог придумать: каким-то программистам, пришедшим из Ruby, сложно без привычных утилит и не хочется переучиваться.
update-alternatives — это не нафига, а для задания интерпретатора по умолчанию. Например, я у себя, в одностороннем порядке, забанил все версии, ниже 3.3. 2.7, конечно, стоит для легаси, но я на него никак не рассчитываю и смело ломаю обратную совместимость, если мне так удобнее. Естественно, я предпочитаю 3.4 в качестве Python по умолчанию в системе. Для этого и нужен update-alternatives.
Про деплой в таком виде, естественно, речи идти даже не может. Хватит того, что зачастую проект дешевле в virtualenv деплоить, чем заниматься пакетированием. При разработке — может быть, но, как я выше написал, всё, что делает pyenv уже давно делается без него и никакую нерешённую проблему я не вижу, единственное объяснение, которое я смог придумать: каким-то программистам, пришедшим из Ruby, сложно без привычных утилит и не хочется переучиваться.
update-alternatives — это не нафига, а для задания интерпретатора по умолчанию. Например, я у себя, в одностороннем порядке, забанил все версии, ниже 3.3. 2.7, конечно, стоит для легаси, но я на него никак не рассчитываю и смело ломаю обратную совместимость, если мне так удобнее. Естественно, я предпочитаю 3.4 в качестве Python по умолчанию в системе. Для этого и нужен update-alternatives.
А я прям боюсь спросить — не пофиг ли какая там версия питона в системе? Мне кажется это проблемы убунты, какая ей там версия нужна.
Программистам из ruby? ;) А с каких пор ubuntu у нас вдруг стала python-way? Пакетирование всего вся? А может яйца тоже надо пакетами ставить? Там вон даже хелперов пук есть ;) Предлагаю запакетировать весь сырный мир.
Программистам из ruby? ;) А с каких пор ubuntu у нас вдруг стала python-way? Пакетирование всего вся? А может яйца тоже надо пакетами ставить? Там вон даже хелперов пук есть ;) Предлагаю запакетировать весь сырный мир.
Ах, да, проходил и совсем забыл попиарить еще такое портированное из ruby мира:
github.com/Deepwalker/pundler
Замена виртуалэнв для разработки, а то все эти virtualenvwrapper это костыли поверх достаточно стремного решения которое не решает огромную тучу вопросов.
github.com/Deepwalker/pundler
Замена виртуалэнв для разработки, а то все эти virtualenvwrapper это костыли поверх достаточно стремного решения которое не решает огромную тучу вопросов.
А какую проблему решает pundler? У меня начинает складываться впечатление, что я совершенно отстал от моды.
От моды просто наглухо, только мода тут ни при чем, чтобы мода это надо на Go срочно идти пилить и монадами присыпать. Даже нода уже не так жгет как в былые времена. Все меняется :)
Pundle решает несколько проблем — он прибивает гвоздями версию пакета во frozen.txt. Он подключает нужные версии пакетов для проекта просто по сладкой парочке файлов — requirements.txt и frozen.txt. И Pundle будет жутко ругаться если вписать пакет в requirements.txt и не запустить процедуру прибивания версии гвоздями.
А еще не будет ситуации как у меня сегодня, когда разработчик закинул код, а пакет не прописал. В случае pundle не прописав пакет, ты просто не сможешь его использовать. Это вам не гадить в virtualenv что попало, это по феншую великого пайтона и пророка его — не пропишешь, не получишь.
Ах, да. Виртуалэнв становится ненужен.
Pundle решает несколько проблем — он прибивает гвоздями версию пакета во frozen.txt. Он подключает нужные версии пакетов для проекта просто по сладкой парочке файлов — requirements.txt и frozen.txt. И Pundle будет жутко ругаться если вписать пакет в requirements.txt и не запустить процедуру прибивания версии гвоздями.
А еще не будет ситуации как у меня сегодня, когда разработчик закинул код, а пакет не прописал. В случае pundle не прописав пакет, ты просто не сможешь его использовать. Это вам не гадить в virtualenv что попало, это по феншую великого пайтона и пророка его — не пропишешь, не получишь.
Ах, да. Виртуалэнв становится ненужен.
Всё понятно. Сарказм по поводу Go не разделяю, у нас в проде есть пример того, что питон, наверное, сегодня не потянет уже совсем без нескольких серверов с десятками гигабайт RAM. На C[++] тогда (да и сейчас) переписывать было некому, а Go — по ощущениям от работы с ним как Python почти, только не однопоточный и типизированный.
У нас похоже сильно разный подход к разработке. Я люблю, когда новая версия библиотеки разламывает нахрен всё и нужно чинить. Ничего гвоздями не прибиваю, люблю переставить полностью виртуальное окружение посреди работы над чем-нибудь. Потом меньше сюрпризов при деплоях и работать не так скучно. А для чтобы не страшно было, для важных частей пишу тесты.
Принципиальной разницы между virtualenv+setup.py (или buildout, например) и pyenv+pundle не увидел. Но раз вам нравится, развлекайтесь, это хорошо, когда инструменты не только дело делают, но и удовольствие от работы с ними доставляют.
У нас похоже сильно разный подход к разработке. Я люблю, когда новая версия библиотеки разламывает нахрен всё и нужно чинить. Ничего гвоздями не прибиваю, люблю переставить полностью виртуальное окружение посреди работы над чем-нибудь. Потом меньше сюрпризов при деплоях и работать не так скучно. А для чтобы не страшно было, для важных частей пишу тесты.
Принципиальной разницы между virtualenv+setup.py (или buildout, например) и pyenv+pundle не увидел. Но раз вам нравится, развлекайтесь, это хорошо, когда инструменты не только дело делают, но и удовольствие от работы с ними доставляют.
Это вы про SlackWare?
Так то все давно deb/rpm/ebuild/tgz делают.
Так то все давно deb/rpm/ebuild/tgz делают.
Ох йо, конечно проще идти скачать версию питона, развернуть ее, поиграться флагами configure. Или например собрать pypy, это еще интереснее, и согреться можно неплохо ноутом в процессе.
А тут выдумали — значит всё уже прописано у хитрых перцев в pyenv, иш, навыдумывали мозг себе не парить.
А тут выдумали — значит всё уже прописано у хитрых перцев в pyenv, иш, навыдумывали мозг себе не парить.
Я в /opt могу и через deb поставить, недавно так Perl на Deb 7.8 обновлял
Вот чисто ради спортивного интереса. Зачем мне может потребоваться 3.3.2 вместо 3.4.2 или что там сейчас стабильного в убунте идет? Там сейчас прекрасно уживаются стейблы и 2 и 3. virtualenv я могу себе сделать с тем или с другим.
> Вот чисто ради спортивного интереса.
> Зачем мне может потребоваться 3.3.2 вместо 3.4.2 или что там сейчас стабильного в убунте идет?
Бывают разные ситуации.
Недавний пример из жизни — twitter.com/mikashkin/status/564077941286371328
> Downgraded #python to make project work. Because of error in urllib2 that can't work with https connections.
> Зачем мне может потребоваться 3.3.2 вместо 3.4.2 или что там сейчас стабильного в убунте идет?
Бывают разные ситуации.
Недавний пример из жизни — twitter.com/mikashkin/status/564077941286371328
> Downgraded #python to make project work. Because of error in urllib2 that can't work with https connections.
Совет №1. Не пишите Вы целиком команду от названия тачки и директории запуска. Ваш тутор пригоден же для копирования должен быть. Просто если нужно, скажите, в какую директорию стоит перейти перед следующей командой.
Совет №2. Объясняйте, почему то, почему это. Для меня до сих пор удобен virtualenv, и создавать виртуалку в нём с 3.4 питоном не сложней, чем «virtualenv --distribute -p python3.4 .env»
Совет №3. Читайте предыдущие статьи на тему. Старенькая habrahabr.ru/post/159575 уже не так актуальна, но в десятки раз понятней, как с чем работать.
Ну и, конечно же, Вы молодец. Развивайтесь.
Совет №2. Объясняйте, почему то, почему это. Для меня до сих пор удобен virtualenv, и создавать виртуалку в нём с 3.4 питоном не сложней, чем «virtualenv --distribute -p python3.4 .env»
Совет №3. Читайте предыдущие статьи на тему. Старенькая habrahabr.ru/post/159575 уже не так актуальна, но в десятки раз понятней, как с чем работать.
Ну и, конечно же, Вы молодец. Развивайтесь.
Sign up to leave a comment.
Пример запуска Django 1.7.4 под Python 3.4.2 на Ubuntu 14.04