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

Question

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

def main():
    args = arguments()
    if not os.path.isfile(args.inventory):
        sys.exit('Please specify valid, readable YAML file with data')

    inventory = get_inventory(args.inventory)
    generate_table(inventory, args)

Вы вызываете get_inventory со строкой, значения из args. Вам также следует вызвать generate_table со значениями из args или самого args. Переоценка args работает, но делает ваш код более грязным.

def generate_table(inventory, args):
    # args = arguments()    # no need to reevaluate args
    data = generate_data(inventory)
    ...

То же самое можно сделать для output_file, хотя не очевидно, где вы используете args.

В generate_table вы, кажется, используете args в основном в:

for arg in vars(args):
    if arg in main_headers and getattr(args, arg):
        main_header.append(arg)
    elif arg in lldp_headers and getattr(args, arg):
        lldp_header.append(arg)
    elif arg in out_file and getattr(args, arg):
        out_file.append(arg)
        output_file(inventory)

Это неясный фрагмент кода, трактующий args как пространство имен и словарь. Я думаю, что это просто проверка значений

args.os_version
args.serial_number
args.lldp
args.outfile

Это все store_true, поэтому они всегда будут присутствовать, и значение True/False. Так что вы могли бы

if args.out_file:
    output_file(inventory)

if args.lldp:
    lldp_header.append('lldp')

Но мне не слишком интересно копаться во всех логических шагах.

Убедитесь, что вы понимаете, что parse_args произвело. Во время отладки я призываю пользователей

 print(args)

Таким образом, будет меньше сюрпризов.

8

egg buildout code-organization svn python

задан 4 revs, 2 users 100% 30 September 2011 в 16:42

3 ответа

Другие вопросы по тегам:

egg buildout code-organization svn python

Похожие вопросы:

score 2 · Answer 1

Поэтому у Вас есть модуль сайта. Это устанавливает внутреннее sys.path включать все пакеты и модули от

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

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

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

В каждом lib запишите a setup.py это развертывает Ваш lib правильно. При внесении изменений Вы делаете svn up собрать изменения и a python setup.py install развернуть одну рабочую копию, которую совместно использует каждое приложение.
В каждом приложении любой зависит от вещей, находящихся в PYTHONPATH переменная среды. Убедитесь это projects/lib1 и projects/lib2 выиграны PYTHONPATH. Каждое приложение затем совместно использует одну рабочую копию различных библиотек.

score 2 · Answer 2

Я имею, используют следующую структуру вполне эффективно. в 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

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

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

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

score 1 · Answer 3

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

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

mkvirtualenv lib1-dev

И затем позже:

workon lib1-dev

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

virtualenv --no-site-packages some-env

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