Python Code Organization Вопрос: яйца + пакеты + сборка + модульные тесты + SVN - PullRequest
8 голосов
/ 11 октября 2008

У меня есть несколько проектов на Python, которые используют общие модули. До сих пор я ... хм ... хранил несколько копий общего кода и синхронизировал вручную. Но я бы предпочел сделать что-то еще.

Теперь мне кажется, как будто zc.Buildout, возможно, то, что мне нужно. Я думаю, что я должен сделать, чтобы поместить каждый повторно используемый компонент моей системы в отдельное яйцо, а затем использовать buildout для сборки их в проекты.

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

Так что, может быть, я хочу что-то вроде этого

projects
  lib1
    tests
    code
  lib2
    tests
    code
  app1
    tests 
    appcode
  app2
    tests
    appcode

и т.д.

Где и app1, и app2 являются независимыми приложениями со своим собственным кодом и тестами, но также включают и используют lib1 и lib2. И lib1 / test, lib1 / code, lib2 / test, lib2code, app1, app2 - это отдельные яйца. Это звучит правильно?

Однако теперь я запутался. Я предполагаю, что при разработке app1 я хочу, чтобы buildout перетаскивал копии lib1, lib2 и app1 в отдельный рабочий каталог, а не помещал копии этих библиотек непосредственно в app1. Но как это работает с моей системой контроля версий SVN? Если рабочий каталог динамически создается с помощью buildout, он не может быть действующим каталогом SVN, из которого я могу проверить изменения обратно в хранилище?

Я неправильно понял, как предполагается использовать buildout? Буду ли я лучше пойти на совершенно другой подход? Как вы смешиваете управление исходным кодом с повторным использованием модулей между проектами?

Обновление: спасибо двум людям, которые в настоящее время ответили на этот вопрос. Я больше экспериментирую с этим.

Ответы [ 4 ]

5 голосов
/ 01 октября 2011

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

Для пакетов библиотеки включите файл buildout.cfg и bootstrap.py в свой пакет, чтобы облегчить запуск тестов. Смотрите, например, пакет plone.reload ; обратите внимание, как он использует zc.recipe.testrunner частей для создания тестового скрипта, который будет автоматически обнаруживать ваши тесты и запускать их. Таким образом, вы можете быть уверены, что ваши библиотечные пакеты всегда тестируются!

Тогда ваши пакеты приложений должны только тестировать интеграцию и код приложения. Опять же, включите тесты с самим пакетом, чтобы не забыть про свои тесты при работе над кодом. Используйте zc.recipe.testrunner детали в вашей сборке, чтобы обнаружить и запустить их.

И последнее, но не менее важное: используйте mr.developer для управления вашими пакетами. С mr.developer вы можете проверять пакеты как работу над ними или полагаться на выпущенные версии, если вам не нужно работать над кодом. У большого проекта будет много зависимостей, многие из которых не требуют настройки кода. С mr.developer вы можете по желанию извлекать исходный код и превращать его в яйца разработки, пока не освободите этот код и не сможете снова отменить извлечение.

Чтобы увидеть реальный пример такой сборки проекта, посмотрите не дальше, чем Сборка разработки ядра Plone .

Файл sources.cfg содержит длинный список местоположений SCM для различных пакетов, но обычно используются выпущенные версии яиц, пока вы явно не активируете пакеты, над которыми вы планируете работать. checkouts.cfg перечисляет все пакеты, извлеченные по умолчанию; Эти пакеты имеют изменения, которые станут частью следующей версии Plone и еще не были выпущены. Если вы работаете над Plone, вы хотите, чтобы они были рядом, потому что вы не можете игнорировать эти изменения. И testing.cfg перечисляет все пакеты, которые нужно протестировать, если вы хотите протестировать Plone, большой список.

Обратите внимание, что источники Plone происходят из самых разных мест. Как только вы начнете использовать buildout и mr.developer для управления вашими пакетами, вы сможете извлекать свой исходный код из любого места.

2 голосов
/ 12 октября 2008

Я достаточно эффективно использовал следующую структуру. в SVN.

Lib1/
   branches/
   tags/
   trunk/
     lib1/
     tests/
     setup.py
Lib2
   branches/
   tags/
   trunk/
     lib2/
     tests/
     setup.py
App1
   branches/
   tags/
   trunk/
     app1/
     tests/
     setup.py
App2
   branches/
   tags/
   trunk/
     app2/
     tests/
     setup.py

Затем я бы создал свое рабочее пространство для разработчиков (я использую eclipse / pydev) следующим образом, извлекая из ствола или ветви.

Lib1/
   lib1/
   tests/
   setup.py
Lib2/
   lib2/
   tests/
   setup.py
App1/
   app1/
   tests/
   setup.py
App2/
   app2/
   tests/
   setup.py

Затем я бы использовал путь Python для установки зависимостей проекта eclipse, который хорошо работает с завершением кода eclipse. setup.py также работает, но не поддерживает наличие нескольких рабочих областей.

Для развертывания я использую создать один zip со следующей структурой.

App1/
   lib1-1.1.0-py2.5.egg/
   lib2-1.1.0-py2.5.egg/
   app1/
   sitecustomize.py

App2/
   lib1-1.2.0-py2.5.egg/
   lib2-1.2.0-py2.5.egg/
   app2/
   sitecustomize.py

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

2 голосов
/ 11 октября 2008

Именно поэтому у вас есть модуль site . Он устанавливает внутренний sys.path для включения всех пакетов и модулей из

  • lib/site-packages - включая каталоги, яйца и .pth файлы.
  • PYTHONPATH

Таким образом, существует ровно одна рабочая копия ваших библиотек.

Существует неограниченное количество способов использовать это. Вот два.

  1. В каждой библиотеке напишите setup.py, которая правильно развертывает вашу библиотеку. Когда вы вносите изменения, вы делаете svn up, чтобы собрать изменения, и python setup.py install, чтобы развернуть одну рабочую копию, которую разделяет каждое приложение.

  2. В каждом приложении либо зависит от того, что находится в переменной окружения PYTHONPATH. Убедитесь, что projects/lib1 и projects/lib2 выиграны PYTHONPATH. Каждое приложение затем разделяет одну рабочую копию различных библиотек.

1 голос
/ 07 января 2009

Я бы рассматривал каждое приложение и библиотеку как яйцо и использовал один из примеров, уже приведенных в плане его размещения в SVN. Действительно, конец вещей VCS не должен быть проблемой.

Затем, для тестирования каждого приложения / библиотеки или комбинации, я бы настроил virtualenv и установил каждый пакет либо через setup.py development, либо через его фактическую установку. Virtualenvwrapper также является полезным инструментом для управления этими средами, так как вы можете просто делать такие вещи, как:

mkvirtualenv lib1-dev

А потом позже:

workon lib1-dev

Virtualenv использует PYTHONPATH, чтобы получить более полный контроль над установленными пакетами. Кроме того, вы можете использовать создание сред с:

virtualenv --no-site-packages some-env

И это исключит любые ссылки на ваши действительные системные пакеты сайта. Это полезно, потому что вы можете не только протестировать свою библиотеку / приложение, но и убедиться, что у вас есть правильные зависимости от установки.

...