Вопрос организации кода Python: яйца + пакеты + сборка + модульные тесты + SVN

У меня есть несколько проектов на 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? Могу ли я выбрать совершенно другой подход? Как совместить управление исходным кодом с повторным использованием модулей между проектами?

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


person Community    schedule 11.10.2008    source источник
comment
Почему недостаточно $ PYTHONPATH?   -  person jfs    schedule 11.10.2008
comment
Я имею в виду: вы сохраняете по одному экземпляру каждого проекта и изменяете $ PYTHONPATH, чтобы находить нужные вам модули из других проектов.   -  person jfs    schedule 11.10.2008


Ответы (4)


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

Для пакетов библиотеки включите в пакет файлы 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 для управления своими пакетами, вы можете свободно извлекать исходный код откуда угодно.

person Community    schedule 01.10.2011

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

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

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

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

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

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

person S.Lott    schedule 11.10.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

Затем я бы использовал либо путь к настройке зависимостей проекта eclipse, либо путь к python, который хорошо работает с завершением кода 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 в пакет развертывания, если это нужно.

person Kozyarchuk    schedule 12.10.2008

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

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

mkvirtualenv lib1-dev

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

workon lib1-dev

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

virtualenv --no-site-packages some-env

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

person Community    schedule 07.01.2009