Пользователь
0,0
рейтинг
12 февраля 2015 в 14:35

Разработка → Пример запуска Django 1.7.4 под Python 3.4.2 на Ubuntu 14.04 из песочницы

Всем привет.



В данном примере я покажу один из способов запуска актуальной версии Django под свежим Python.

Python 3.4.2 | Release Date: 2014-10-13
Django 1.7.4 | January 27, 2015

Будут использованы virtualenvwrapper и pyenv:
— virtualenvwrapper будет работать с «системным» python2
— используем pyenv для установки последней версии Python
— используем virtualenvwrapper для создания виртуального окружения с последней версей Python «внутри»

Информация про систему


Запуск будет производится на Ubuntu 14.04.1 LTS:

devel787@vbox64:~$ uname -a
Linux vbox64 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

devel787@vbox64:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty


После установки Ubuntu по умолчанию доступен bash:

devel787@vbox64:~$ echo $SHELL
/bin/bash

devel787@vbox64:~$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)


Также по умолчанию сразу предустановлены 2 версии Python:

devel787@vbox64:~$ python --version
Python 2.7.6

devel787@vbox64:~$ python3 --version
Python 3.4.0


Установка virtualenvwrapper


virtualenvwrapper представляет из себя удобную обёртку вокруг virtualenv.

Для установки virtualenvwrapper необходимо выполнить некоторые действия.

Получаем новые списки пакетов Ubuntu:

devel787@vbox64:~$ sudo apt-get update


Устанавливаем pip:

devel787@vbox64:~$ sudo apt-get install python-pip


Устанавливаем virtualenvwrapper:

devel787@vbox64:~$ sudo pip install virtualenvwrapper


Настраиваем virtualenvwrapper:

devel787@vbox64:~$ echo '' >> ~/.bashrc

devel787@vbox64:~$ echo '# virtualenvwrapper' >> ~/.bashrc

devel787@vbox64:~$ echo 'export WORKON_HOME=$HOME/.virtualenvs' >> ~/.bashrc

devel787@vbox64:~$ echo 'export PROJECT_HOME=$HOME/vwrapperhome' >> ~/.bashrc

devel787@vbox64:~$ echo 'source /usr/local/bin/virtualenvwrapper.sh' >> ~/.bashrc

devel787@vbox64:~$ echo '' >> ~/.bashrc


Создаём папку для PROJECT_HOME из настроек выше:

devel787@vbox64:~$ mkdir ~/vwrapperhome


Применяем настройки:

devel787@vbox64:~$ source ~/.bashrc


Теперь у нас должны быть доступны команды virtualenvwrapper, например:

devel787@vbox64:~$ workon

devel787@vbox64:~$ virtualenvwrapper


Установка pyenv


pyenv представляет из себя удобную утилиту для управления версиями Python.

Для установки pyenv необходимо выполнить некоторые действия.

Устанавливаем нужные зависимости:

devel787@vbox64:~$ sudo apt-get install make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm


Устанавливаем git:

devel787@vbox64:~$ sudo apt-get install git


Устанавливаем pyenv:

devel787@vbox64:~$ cd

devel787@vbox64:~$ git clone git://github.com/yyuu/pyenv.git .pyenv


Настраиваем pyenv:

devel787@vbox64:~$ echo '' >> ~/.bashrc

devel787@vbox64:~$ echo '# pyenv' >> ~/.bashrc

devel787@vbox64:~$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc

devel787@vbox64:~$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc

devel787@vbox64:~$ echo 'eval "$(pyenv init -)"' >> ~/.bashrc

devel787@vbox64:~$ echo '' >> ~/.bashrc


Применяем настройки:

devel787@vbox64:~$ exec $SHELL


Теперь у нас должны быть доступны команды pyenv, например можно посмотреть версию утилиты:

devel787@vbox64:~$ pyenv --version
pyenv 20150204


Установка Python 3.4.2


pyenv предоставляет возможность установить много разных версий Python.

Для просмотра всех доступных версий необходимо выполнить:
devel787@vbox64:~$ pyenv install --list
Available versions:
  2.1.3
  2.2.3
  2.3.7
  2.4
  2.4.1
  2.4.2
  2.4.3
  2.4.4
  2.4.5
  2.4.6
  2.5
  2.5.1
  2.5.2
  2.5.3
  2.5.4
  2.5.5
  2.5.6
  2.6.6
  2.6.7
  2.6.8
  2.6.9
  2.7-dev
  2.7
  2.7.1
  2.7.2
  2.7.3
  2.7.4
  2.7.5
  2.7.6
  2.7.7
  2.7.8
  2.7.9
  3.0.1
  3.1-dev
  3.1.3
  3.1.4
  3.1.5
  3.2-dev
  3.2
  3.2.1
  3.2.2
  3.2.3
  3.2.4
  3.2.5
  3.2.6
  3.3.0
  3.3-dev
  3.3.1
  3.3.2
  3.3.3
  3.3.4
  3.3.5
  3.3.6
  3.4.0
  3.4-dev
  3.4.1
  3.4.2
  3.5-dev
  anaconda-1.4.0
  anaconda-1.5.0
  anaconda-1.5.1
  anaconda-1.6.0
  anaconda-1.6.1
  anaconda-1.7.0
  anaconda-1.8.0
  anaconda-1.9.0
  anaconda-1.9.1
  anaconda-1.9.2
  anaconda-2.0.0
  anaconda-2.0.1
  anaconda-2.1.0
  anaconda3-2.0.0
  anaconda3-2.0.1
  anaconda3-2.1.0
  ironpython-dev
  ironpython-2.7.4
  ironpython-2.7.5
  jython-dev
  jython-2.5.0
  jython-2.5-dev
  jython-2.5.1
  jython-2.5.2
  jython-2.5.3
  jython-2.5.4-rc1
  jython-2.7-beta1
  jython-2.7-beta2
  jython-2.7-beta3
  miniconda-2.2.2
  miniconda-3.0.0
  miniconda-3.0.4
  miniconda-3.0.5
  miniconda-3.3.0
  miniconda-3.4.2
  miniconda-3.7.0
  miniconda3-2.2.2
  miniconda3-3.0.0
  miniconda3-3.0.4
  miniconda3-3.0.5
  miniconda3-3.3.0
  miniconda3-3.4.2
  miniconda3-3.7.0
  pypy-c-jit-latest
  pypy-c-nojit-latest
  pypy-dev
  pypy-1.5-src
  pypy-1.5
  pypy-1.6
  pypy-1.7-dev
  pypy-1.7
  pypy-1.8-dev
  pypy-1.8
  pypy-1.9-dev
  pypy-1.9
  pypy-2.0-dev
  pypy-2.0-src
  pypy-2.0
  pypy-2.0.1-src
  pypy-2.0.1
  pypy-2.0.2-src
  pypy-2.0.2
  pypy-2.1-src
  pypy-2.1
  pypy-2.2-src
  pypy-2.2
  pypy-2.2.1-src
  pypy-2.2.1
  pypy-2.3-src
  pypy-2.3
  pypy-2.3.1-src
  pypy-2.3.1
  pypy-2.4.0-src
  pypy-2.4.0
  pypy-2.4-beta1-src
  pypy-2.4-beta1
  pypy-2.5.0-src
  pypy-2.5.0
  pypy3-dev
  pypy3-2.3.1-src
  pypy3-2.3.1
  pypy3-2.4.0-src
  pypy3-2.4.0
  stackless-dev
  stackless-2.7-dev
  stackless-2.7.2
  stackless-2.7.3
  stackless-2.7.4
  stackless-2.7.5
  stackless-2.7.6
  stackless-2.7.7
  stackless-2.7.8
  stackless-3.2-dev
  stackless-3.2.2
  stackless-3.2.5
  stackless-3.3-dev
  stackless-3.3.5
  stackless-3.4.1




Устанавливаем Python 3.4.2:

devel787@vbox64:~$ pyenv install 3.4.2 -v


Выполняем 'rehash' (Rebuild the shim binaries. You should do this any time you install a new Python binary):

devel787@vbox64:~$ pyenv rehash


Для просмотра установленных версий Python необходимо выполнить:

devel787@vbox64:~$ pyenv versions
* system (set by /home/devel787/.pyenv/version)
  3.4.2


Создание виртуального окружения


Теперь можно создать виртуальное окружение на базе Python 3.4.2.

По умолчанию бинарный файл Python 3.4.2 будет доступен в '~/.pyenv/versions/':

devel787@vbox64:~$ ls -lahF ~/.pyenv/versions/3.4.2/bin/python
lrwxrwxrwx 1 devel787 devel787 9 Feb 10 16:24 /home/devel787/.pyenv/versions/3.4.2/bin/python -> python3.4*


Создаём виртуальное окружение (и сразу оказываемся “внутри” него):

devel787@vbox64:~$ mkvirtualenv -p ~/.pyenv/versions/3.4.2/bin/python polls174-py342-venv


Проверяем версию Python:

(polls174-py342-venv)devel787@vbox64:~$ python --version
Python 3.4.2


Для выхода из виртуального окружения необходимо выполнить:

(polls174-py342-venv)devel787@vbox64:~$ deactivate


Для просмотра всех виртуальных окружений необходимо выполнить:

devel787@vbox64:~$ workon
polls174-py342-venv


Попасть “обратно” в виртуальное окружение можно выполнив:

devel787@vbox64:~$ workon polls174-py342-venv


Запуск Django 'polls' app


Для демонстрации работоспособности Django 1.7.4 под Python 3.4.2 запустим Django 'polls' app из Django Tutorial.

Я создал репозиторий, который содержит выполненный Django Tutorial и файл 'requirements.txt'.

Перейдём в папку для PROJECT_HOME из настроек выше:

(polls174-py342-venv)devel787@vbox64:~$ cd ~/vwrapperhome/


«Склонируем» себе репозиторий, который содержит выполненный Django Tutorial:

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome$ git clone https://github.com/devel787/polls174.git


Перейдём в папку с проектом:

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome$ cd polls174/


«Закрепим» папку проекта за нашим виртуальным окружением (при активации окружения мы будем попадать в эту папку):

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome/polls174$ setvirtualenvproject
Setting project for polls174-py342-venv to /home/devel787/vwrapperhome/polls174


Установим Django 1.7.4:

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome/polls174$ pip install -r requirements.txt


Запустим тесты:

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome/polls174$ python manage.py test


Запустим сервер для разработки:

(polls174-py342-venv)devel787@vbox64:~/vwrapperhome/polls174$ python manage.py runserver


Теперь можно перейти по ссылке
http://127.0.0.1:8000/polls/
и увидеть результаты работы данного примера.
Для /admin/ Username == Password == 'admin'.

Литература


Virtual Environments | The Hitchhiker's Guide to Python
virtualenvwrapper | Installation
pyenv | Installation

Blast into PyEnv [18 сентября 2014]
Building Python on Ubuntu with pyenv [02 марта 2014]
Менеджер версий python [25 ноября 2013]
Мульти-хостинг django приложений с помощью nginx + uwsgi + virtualenv [15 мая 2013]

Writing your first Django app, part 1
@devel787
карма
2,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (44)

  • +3
    Почему выполняются эти, а не какие-либо иные действия? Где объяснения?
    Всю эту «статью» можно пересказать одной ссылкой на provision.sh.
    • –1
      > Почему выполняются эти, а не какие-либо иные действия?

      Потому что эта последовательность действий приводит к описанному в примере результату.
      И как и написано в самом начале — это только один из возможных вариантов, который лично для меня в текущий момент является наиболее удобным.

      > Где объяснения?

      Я старался описывать действия до примера вызова команды.
      В целом ответить на такой вопрос довольно непросто.
      Если у вас есть конкретные примеры непонятных действий — напишите, а я постараюсь написать объяснения по-другому, да побольше.

      > Всю эту «статью» можно пересказать одной ссылкой на 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
      Дайте, пожалуйста, прямую ссылку.
      После «ознакомления» я смогу ответь что-то более внятное.
      • 0
        Это намек на то, что стоило бы освоить Vagrant
        • –1
          > Это намек на то, что стоило бы освоить Vagrant

          Vagrant освоен и используется ежедневно.
          Но для меня он не пересекается с темой примера.

          Данный пример показывает как запуститься на локальной машине,
          а не «поднимать» виртуальную — «руками» или Vagrant'ом, не суть.

          Ничто не мешает проделать подобные действия внутри «виртуалки» — «руками» или через Ansible, например.
          • 0
            Тогда вы бы знали, что имеется в виду под provision
            • –1
              > Тогда вы бы знали, что имеется в виду под provision

              У меня есть опыт использования 'vagrant provision' — docs.vagrantup.com/v2/cli/provision.html
              Конкретнее 'Ansible Provisioner' — docs.vagrantup.com/v2/provisioning/ansible.html

              А именно с 'provision.sh' я ещё не сталкивался, я уже писал об этом «выше».
      • +2
        Перед написанием статьи надо определиться с целевой аудиторией.
        Если статья для новичков, надо описывать не только выполняемые действия, но и их значение.
        Если статья для продвинутых, то мимо, в статье элементарщина.
        Вы промахнулись мимо какой-либо ЦА.

        > Более того я не смог понять какой именно 'provision.sh' имеется в виду при поиске в google.
        Эту статью можно сократить до одного файла с инструкциями для vagrant, по которому поднимется сервер. Руками это делать незачем.
        • –1
          > Перед написанием статьи надо определиться с целевой аудиторией.
          > Если статья для новичков, надо описывать не только выполняемые действия, но и их значение.
          > Если статья для продвинутых, то мимо, в статье элементарщина.
          > Вы промахнулись мимо какой-либо ЦА.

          Скорее всего сейчас у меня не хватает навыка «попадания в ЦА».
          Я написал этот пример так, как бы сам хотел его видеть.
          Постараюсь это учесть в следующий раз.

          > Эту статью можно сократить до одного файла с инструкциями для vagrant, по которому поднимется сервер.

          Да, можно.
          Но данный пример показывает как запуститься на локальной машине, а не «поднимать» виртуальную.

          > Руками это делать незачем.

          Тут я с вами не согласен.
          Лично мне сейчас нравится это делать «руками», как в примере, а не «городить виртуалки».
          Возможно кому-нибудь ещё пригодится какая-нибудь часть моего примера.
          • –1
            > Но данный пример показывает как запуститься на локальной машине, а не «поднимать» виртуальную.
            А разве есть какая-то разница в действиях при разворачивании окружения для реальной машины и виртуалки? o_O

            > мне сейчас нравится это делать «руками»
            Офигеть, какой обоснованный довод. «Мне нравится». А мне в детстве нравилось в грязной луже сидеть и ладошками по поверхности шлепать.
            • 0
              > А разве есть какая-то разница в действиях при разворачивании окружения для реальной машины и виртуалки? o_O

              На локальной машине (с которой сейчас открыт firefox и я набираю этот комментарий)
              лично мне достаточно иметь виртуальное окружение с Python 3.4.2 «внутри».

              Этого вполне хватает для моей «песочницы» и разворачивается «руками» за 10-15 минут
              путём вдумчивого копирования команд из этого примера.
              Причём необходимость «разворачивать» возникает далеко не каждый день.

              Когда у меня будет необходимость «развернуться» на сервере или внутри виртуалки
              я выделю немного времени и «заверну» всё необходимое в Ansible.

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

              > Офигеть, какой обоснованный довод. «Мне нравится».

              Я хотел бы уточнить с чего вы взяли, что я обязан перед вами оправдываться?

              Свои доводы я написал «выше», но они для вас несущественны.

              Я хочу ещё раз прояснить:

              > Я написал этот пример так, как бы сам хотел его видеть.

              Как я понял, если мой пример всем-всем не понравится,
              то я получу много-много минусов от сообщества
              и не смогу больше писать свои мысли на habr.ru.

              > А мне в детстве нравилось в грязной луже сидеть и ладошками по поверхности шлепать.

              Рад за вас, но это никак не относится к теме моего примера.

              Если вы хотите и можете помочь — напишите в комментарии «как нужно»,
              тогда я поправлю пример и все будут счастливы.
  • 0
    а почему не докер?
    • 0
      > а почему не докер?

      Сейчас у меня нет достаточных навыков, чтобы написать такой же пример с применением Docker-контейнера.
      Я был бы очень рад увидеть подобного рода пример на habr.ru, т.к. мне тоже интересна эта тема.
      • 0
        Для примера — возьмити официальный ман по развертыванию постгреса через докер.
        А вообще, у меня материала на статью есть, только надо сесть и расписать — я тут кластер из 2х нод поднял, может кому пригодится материал
  • +4
    А в чем сложность?
    • –1
      > А в чем сложность?

      Не могу понять «контекст» вопроса.
      Уточните, пожалуйста, о сложности чего именно вы бы хотели узнать?
      • +2
        В чем сложность запуска Django 1.7.4 под Python 3.4.2 на Ubuntu 14.04?
        • 0
          > В чем сложность запуска 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 «внутри».
  • 0
    Зачем этот цирк с pyenv? Ещё сегодня утром Ubuntu базировалась на Debian, а не на Slackware. Зачем игнорировать существующую бинарную дистрибуцию и предоставляемые ей инструменты, да ещё и таким извращённым образом? Всё то, что делает pyenv можно сделать без него при помощи update-alternatives и virtualenv. Собственно, там в документации неявно и написана аудитория этого проекта: «This project was forked from rbenv and ruby-build, and modified for Python».

    Чем этот метод лучше всех остальных, описанных раньше?
    • +2
      > Зачем этот цирк с 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' недостаточно для решения подобной задачи,
      но я бы очень хотел научиться не игнорировать, а наоборот — использовать существующую бинарную дистрибуцию
      и предоставляемые ей инструменты.

      Расскажите, пожалуйста, как это сделать правильно.
      У меня есть подозрения, что это будет интересно узнать не только мне.
      • –3
        Совет для Debian:

        man apt-get
        man update-alternatives
        man dpkg

        Очень сомневаюсь, что в Ubuntu это поломано, но проверить не могу, так как нигде Ubuntu не использую.

        Прочитаете — пишите вопросы, будем разбирать предметно.
    • 0
      pyenv переключает нужную версию питона просто по файлу .pyenv-version в корне проекта. Например в нужном проекте сработает python2.7, в другом 3.4.1.
      pyenv может легко поставить любую версию python, в том числе и последние свежие pypy и тому подобное.
      То что его идея пришла из мира руби не делает её плохой.
      Чуваки из дебиан немного странные и сломали easy_pip как-то раз, с совершенно тупой аргументацией. В итоге python -m venv пошел лесом.

      Но учитывайте же, что это всё инструменты для удобной разработки — деплоить через pyenv я не рекомендую — при деплое вполне возможно воткнуть на сервер правильную версию интерпретатора с помощью какого-либо репо.

      update_alternatives — ооочень странные рекомендации — нафига? В стартовом скрипте укажите полный путь до нужной версии, всё будет работать без этой фигни странной.
      • 0
        Я, видимо, не понимаю, какую нерешённую проблему решает pyenv, и от этого не могу понять, что вы мне пытаетесь донести. Может быть имеет смысл начать с этого. Манипулировать PATH для вызова нужного интерпретатора умеет virtualenv, активировать virtualenv при заходе в директорию умеет шелл (очень тривиально делается, я в это игрался, но выбросил очень быстро, у меня не прижилось). Поставить любую версию интерпретатора может пакетный менеджер. Кода для создания правил сборки пакетов в коде pyenv нет, он просто разводит банальную слаку в ~/.pyenv/versions. Для меня это так же отвратительно, как не мыть руки после посещения туалета.

        Про деплой в таком виде, естественно, речи идти даже не может. Хватит того, что зачастую проект дешевле в virtualenv деплоить, чем заниматься пакетированием. При разработке — может быть, но, как я выше написал, всё, что делает pyenv уже давно делается без него и никакую нерешённую проблему я не вижу, единственное объяснение, которое я смог придумать: каким-то программистам, пришедшим из Ruby, сложно без привычных утилит и не хочется переучиваться.

        update-alternatives — это не нафига, а для задания интерпретатора по умолчанию. Например, я у себя, в одностороннем порядке, забанил все версии, ниже 3.3. 2.7, конечно, стоит для легаси, но я на него никак не рассчитываю и смело ломаю обратную совместимость, если мне так удобнее. Естественно, я предпочитаю 3.4 в качестве Python по умолчанию в системе. Для этого и нужен update-alternatives.
        • 0
          А я прям боюсь спросить — не пофиг ли какая там версия питона в системе? Мне кажется это проблемы убунты, какая ей там версия нужна.

          Программистам из ruby? ;) А с каких пор ubuntu у нас вдруг стала python-way? Пакетирование всего вся? А может яйца тоже надо пакетами ставить? Там вон даже хелперов пук есть ;) Предлагаю запакетировать весь сырный мир.
          • 0
            Мне не всё равно. Я часто использую ipython для всяких экспериментов или одноразовых наколенных поделок. Опять же, как калькулятор очень удобно.

            При чём тут убунта к питону-то? Они давже в разных абзацах же. Что пакетировать и с какой гранулярностью зависит от целей.
    • 0
      Ах, да, проходил и совсем забыл попиарить еще такое портированное из ruby мира:
      github.com/Deepwalker/pundler

      Замена виртуалэнв для разработки, а то все эти virtualenvwrapper это костыли поверх достаточно стремного решения которое не решает огромную тучу вопросов.
      • 0
        А какую проблему решает pundler? У меня начинает складываться впечатление, что я совершенно отстал от моды.
        • 0
          От моды просто наглухо, только мода тут ни при чем, чтобы мода это надо на Go срочно идти пилить и монадами присыпать. Даже нода уже не так жгет как в былые времена. Все меняется :)

          Pundle решает несколько проблем — он прибивает гвоздями версию пакета во frozen.txt. Он подключает нужные версии пакетов для проекта просто по сладкой парочке файлов — requirements.txt и frozen.txt. И Pundle будет жутко ругаться если вписать пакет в requirements.txt и не запустить процедуру прибивания версии гвоздями.

          А еще не будет ситуации как у меня сегодня, когда разработчик закинул код, а пакет не прописал. В случае pundle не прописав пакет, ты просто не сможешь его использовать. Это вам не гадить в virtualenv что попало, это по феншую великого пайтона и пророка его — не пропишешь, не получишь.

          Ах, да. Виртуалэнв становится ненужен.
          • 0
            Всё понятно. Сарказм по поводу Go не разделяю, у нас в проде есть пример того, что питон, наверное, сегодня не потянет уже совсем без нескольких серверов с десятками гигабайт RAM. На C[++] тогда (да и сейчас) переписывать было некому, а Go — по ощущениям от работы с ним как Python почти, только не однопоточный и типизированный.

            У нас похоже сильно разный подход к разработке. Я люблю, когда новая версия библиотеки разламывает нахрен всё и нужно чинить. Ничего гвоздями не прибиваю, люблю переставить полностью виртуальное окружение посреди работы над чем-нибудь. Потом меньше сюрпризов при деплоях и работать не так скучно. А для чтобы не страшно было, для важных частей пишу тесты.

            Принципиальной разницы между virtualenv+setup.py (или buildout, например) и pyenv+pundle не увидел. Но раз вам нравится, развлекайтесь, это хорошо, когда инструменты не только дело делают, но и удовольствие от работы с ними доставляют.
            • 0
              Огонь, проблема в том, что в вашем случае всё разлетится именно во время деплоя. Я такой подход не то чтобы не разделяю, у меня такой подход кончается увольнением персонажа.
              • 0
                Прямо противоположный опыт: всё, что могло отломаться — отламывается и чинится на локалхосте, а при деплоях всё как по маслу. Я это называю «CI для бедных».
  • +1
    Чем только люди не занимаются, лишь бы не делать ./configure && make && sudo make install… :D
    • 0
      Это вы про SlackWare?
      Так то все давно deb/rpm/ebuild/tgz делают.
      • 0
        Это я в шутку :) Просто одно время была мода поливать помоями эту комбинацию, мол, все что угодно, но только не это. Ясен пень, что у такого подхода есть серьезные недостатки, и в обход пакетного менеджера лучше ничего не ставить. Но если очень хочется ивратиться и поставить «левую» версию питона, то, имхо, проще её поставить, например, в /opt// через make, чем городить огород, как предлагает автор.
        • –1
          Ох йо, конечно проще идти скачать версию питона, развернуть ее, поиграться флагами configure. Или например собрать pypy, это еще интереснее, и согреться можно неплохо ноутом в процессе.
          А тут выдумали — значит всё уже прописано у хитрых перцев в pyenv, иш, навыдумывали мозг себе не парить.
          • +1
            Нуу… Как бы, действительно ничего сложного:

            $ cd /tmp
            $ wget https://www.python.org/ftp/python/3.3.6/Python-3.3.6.tgz
            $ tar xf Python-3.3.6.tgz
            $ cd Python-3.3.6
            $ ./configure --prefix=/opt/python336
            $ make -j3
            $ sudo make install
            $ /opt/python336/bin/python3 --version
            Python 3.3.6
            
            $ wget https://bootstrap.pypa.io/ez_setup.py -O - |  /opt/python336/bin/python3
            
            $ cd /tmp/
            $ wget https://pypi.python.org/packages/source/p/pip/pip-6.0.8.tar.gz
            $ tar xf pip-6.0.8.tar.gz
            $ cd pip-6.0.8
            $ sudo /opt/python336/bin/python3 setup.py install
            
            $ sudo /opt/python336/bin/pip install django
            ...
            Successfully installed django-1.7.4
            

            • +1
              UPD. Не, конечно, я понимаю, что если нужно иметь зоопарк из версий питона, то pyenv будет удобнее. Но зачем обычному веб-разработчику, например, — если он, конечно, не мейнтейнер какой-то либы — целый зоопарк питонов? А для единичного случая… у меня ушло минут 10-15 на поиск ссылок на скачивание, компиляцию, установку пакетов и написание комментария.

              P.S. А вообще арчик рулит ;)

              $ python3 --version
              Python 3.4.2
              
              $ python2 --version
              Python 2.7.9
            • 0
              pyenv install 3.4.2
        • +1
          Я в /opt могу и через deb поставить, недавно так Perl на Deb 7.8 обновлял
          • +1
            Тоже круто. А если не секрет, как? А то лень гуглить, а может пригодиться.
            • 0
              make configure, и выставить пути ручками.
              dpkg при попытке поставить проверяет, с перлом валится на пакет perl-core или как-то так, он в систему врезан так наглухо, что или perlbrew, или в /opt. Ну, или как я сейчас модули cpan в докер заворачиваю, наверное, на днях таки разрожусь инструкцией
              • 0
                Спасибо. Я думал, можно уже готовый deb поставить куда-то в другое место, как бы префикс указать ему, от чего корень отсчитывать.
  • 0
    Вот чисто ради спортивного интереса. Зачем мне может потребоваться 3.3.2 вместо 3.4.2 или что там сейчас стабильного в убунте идет? Там сейчас прекрасно уживаются стейблы и 2 и 3. virtualenv я могу себе сделать с тем или с другим.
    • +2
      > Вот чисто ради спортивного интереса.
      > Зачем мне может потребоваться 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.
  • 0
    Совет №1. Не пишите Вы целиком команду от названия тачки и директории запуска. Ваш тутор пригоден же для копирования должен быть. Просто если нужно, скажите, в какую директорию стоит перейти перед следующей командой.
    Совет №2. Объясняйте, почему то, почему это. Для меня до сих пор удобен virtualenv, и создавать виртуалку в нём с 3.4 питоном не сложней, чем «virtualenv --distribute -p python3.4 .env»
    Совет №3. Читайте предыдущие статьи на тему. Старенькая habrahabr.ru/post/159575 уже не так актуальна, но в десятки раз понятней, как с чем работать.
    Ну и, конечно же, Вы молодец. Развивайтесь.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.