Лучшие практики для сохранения зависимостей Python GAE в проекте VCS

Question

Лучшие практики для сохранения зависимостей Python GAE в проекте VCS

1

В нашей компании у нас очень хорошая система для отслеживания зависимостей внешних пакетов в управлении версиями для нашей текущей разработки настольных приложений (С++/python). Мы начинаем разрабатывать некоторые python. Только веб-приложения ищут рекомендации по лучшим практикам, когда есть только код Python, и он приходит из пакетов easy_install'able.

Для наших настольных приложений у нас есть что-то вроде этого:

app_svn_root
  - trunk
    - src
    - doc
    - deps -> [svn:external to deps repos with rev num set]

deps_svn_root
  - trunk
    - setup_env.sh/bat  [generated automatically
    - dep_project_1 [example: boost, libxml, python, etc]
       - vendor_base [svn:external to vendor branch or project repository]
       - install_linux_gcc43
         - bin
         - include
         - lib
       - install_linux_win32_vc90
         - ...   [whatever directory structure the project build creates]

Когда любой разработчик в команде проверяет код для приложения, он автоматически получает все зависимости и получает их с правильной версией для этой версии кода. [примечание: есть несколько внутренних сценариев управления и т.д., которые я забыл, но это общая идея]. Это отлично работает для нас. Ни один разработчик не должен больше беспокоиться о настройке своей персональной машины с каждым пакетом с правильной версией, что позволяет одновременно проверять несколько копий разработки (например: версия 1.0, 1.1, 2.0 и т.д.), И это позволяет система непрерывной интеграции для упаковки зависимостей и выполнения модульных тестов с правильной версией отпечатков.

Теперь мы начинаем работать над некоторыми проектами на основе python на основе Google, и нам нужно что-то подобное выше. Мы хотим сохранить способность иметь разработчика, чтобы проверить все, что им нужно сразу, и гарантировать, что все используют одни и те же зависимости. Мы могли бы использовать эту точную структуру, но, по-видимому, она имеет большой вес для чистого проекта python.

Изначально я думал о чем-то вроде этого:

- trunk
  - gae_apps
    - gae_sdk  [svn:external to the latest stable GAE code]
    - deps
      - nose
      - nosegae
      - pylint
    - app1
      - templates
      - tests
      - deps
        - webapp2
        - console

Проблема, с которой я сталкиваюсь, заключается в том, что все проекты python, которые я хочу использовать (нос, носги и т.д.), рекомендую использовать easy_install для их загрузки и установки. Однако это устанавливает их в основной системный каталог. Я действительно хочу, чтобы код был установлен в определенный каталог для каждого пакета. (примечание: я планировал поместить некоторый код в main.py, который добавит все пакеты в deps в sys.path правильно). Есть ли способ сделать это? Это даже хорошая идея?

Каковы наилучшие методы отслеживания зависимостей в чистых приложениях python для поддержки разработки с большими командами?

Allen 11 сен. 2010, в 17:33

Источник

0

примечание: я не думаю, что я могу использовать virtualenv. Первая причина в том, что он не работает с носовыми морщинами. (см .: code.google.com/p/nose-gae/issues/detail?id=11 ), а во-вторых, я думаю, что это не соответствует моей цели - команда разработчиков может просто проверить хранилище и получить все тогда надо бежать. (т.е. я не думаю, что вы можете совершить virtualenv для VCS). Пожалуйста, скажите мне, если я ошибаюсь. :)
Allen 12 сен. 2010, в 13:46

Теги:

python

google-app-engine

easy-install

3 ответа

Ещё вопросы

примечание: я не думаю, что я могу использовать virtualenv. Первая причина в том, что он не работает с носовыми морщинами. (см .: code.google.com/p/nose-gae/issues/detail?id=11 ), а во-вторых, я думаю, что это не соответствует моей цели - команда разработчиков может просто проверить хранилище и получить все тогда надо бежать. (т.е. я не думаю, что вы можете совершить virtualenv для VCS). Пожалуйста, скажите мне, если я ошибаюсь. :)

Roberto Bonvallet · Answer 1 · 2010-09-11T12-42-00.000Z

Вы можете использовать virtualenv + pip. С помощью virtualenv вы можете создавать настраиваемые среды для своего приложения, где все пакеты устанавливаются локально с помощью pip (замена easy_install) в среде, а не в масштабах всей системы. Затем вы можете создать список зависимостей для их автоматического установки.

Я думал о том, чтобы сделать это, но я не видел способа установить зависимости в каталог контроля версий. По сути, я хочу, чтобы virtualenv извлекался из общего каталога (или каталогов) в извлеченном коде проекта. (другими словами, я не хочу, чтобы разработчики устанавливали что-либо на свои локальные машины, просто проверьте репозиторий и отправляйтесь)
Изучив это подробнее, я попытался использовать pip -E .../deps nose для установки пакетов. Я видел в Интернете некоторые ссылки, в которых говорилось, что это должно работать, но это не так. Я думаю, что pip должен быть нацелен на стандарт или virtualenv и не может просто нацелиться на каталог, где я хочу разместить пакеты Я все еще ищу вокруг, чтобы найти решение.

Sudhir Jonathan · Answer 2 · 2012-11-23T16-49-00.000Z

Я использую zc.buildout с рецептами, первоначально написанными для Tipfy: посмотрите https://github.com/runway7/terminal для примера buildout.cfg.

Установить zc.buildout - pip install zc.buildout
Создайте buildout.cfg в пустом каталоге проекта, а также скопируйте versions.cfg из примера. Настройте версию GAE в buildout.cfg
Запустите buildout и исправьте заданные ошибки. (В принципе просто создайте каталоги структуры.)
Просто добавьте любые зависимости в раздел eggs buildout.cfg, чтобы он управлял ими для вас.

Отлично работает для меня.

Nathan · Answer 3 · 2011-10-18T06-11-00.000Z

Я также пытался выяснить, какой лучший способ получить автоматическое разрешение зависимостей в проектах Python, используя Ivy и Maven с Java-проектами.

Из того, что я могу сказать, в Python ничего не работает, как Maven, но zc.buildout, кажется, очень близко. Он использует ту же традиционную distutils setup.py script, что и с pip/distribute, но предлагает большую гибкость в том, как вы строите свои проекты. Это не требует возиться с virtualenv, но все же предлагает изолированную среду сборки.

Затем вы должны настроить локальный экземпляр Pypi и использовать его как репозиторий для всех ваших зависимостей на Python.

Если ваши зависимости все чистые Python, тогда это должно работать очень хорошо. Если у вас есть зависимости от собственного кода, у вас могут возникнуть проблемы. Существуют рецепты сборки, чтобы сделать это возможным, и вы можете легко создавать свои собственные пользовательские.

Если каждый разработчик установил свойство кэша загрузки в файле ~/.buildout/default.cfg, это необходимо, если вы вытягиваете зависимости через Интернет.