В учебниках как-то слабо описана технология разработки ПО на питоне поэтому у меня как у новичка возникло несколько вопросов.

Я делаю примерно так:

Настройка системы разработки:
Вначале ставится питон easy_install.exe swig и pyscripter (Я после wolfram mathematica привык выделять блоки кода в текстовом редакторе и их выполнять в хаотическом порядке пока не получится что-нибудь работающее поэтому pyscripter). Ставлю именно python26 поскольку для него больше готовых пакетов и плачу по python31 хотя по тестом вроде у него упала производительность.
Потом запчасти numpy,wxwidgets, scipy. Ну тут конечно каждому свое.

Организация проектов:
Проекты раскладываются по директориям внутри если надо организуются директории с данными и пакетами данного проекта. Разработка начинается обычно с одного файла в котором растет скрипт. По мере роста из него вырезаются в отдельные модули - он почкуется. Если и модулей становится много - они прячутся в пакеты. Этот процесс естественно активен только в самом начале проекта.

1) Вопрос. Как при почковании или создании пакетов править в проекте import? Я делаю множественные замены во всех файлах текстовым редактором. А вы?

Кроме того есть общая как-бы библиотека (мой пакет используемый во всех проектах) В нем конечно тоже что-то постоянно добавляется.

2) Вопрос. Этот общий пакет что - все время инсталлировать в питон? Я пока до этого не дорос и поэтому в директории Python26\Lib\site-packages\ положил mypack.pth и внем написал путь к директории где лежит директория с общим пакетом и на этом успокоился (т.е. ничего не инсталлирую).

Я к сожалению не могу обойтись без отладки. С питоном ясно а вот с кусками кода на других языках (привязаны swig или просто через ctypes) неясно. Я их компилирую вроде как релиз но курочу опции чтобы и отладочная информация была (это MSVC 2010 fortran и прочие радости жизни). Делал и отладочную версию питона - но как ее прикрутить к pyscripter? В отладчике говорю что надо запускать pyscripter –PYTHON26 tested.py и отлаживаю мою dll.

Распространение Трудности возникают когда ставится ПО людям у которых нет интернета (а их очень много).

3) Вопрос. Как заставить easy_install.exe выкачать нужные мне части на локальный диск? Вроде может но отказыватся.

Поэтому инсталляция пока проста - пользователям без интернета - копируется полная версия моей директории с питоном (бейте меня не сильно.)

Вобщем самый лучший узел беседочный? Да?

Хм… Я предпочитаю сразу разбить проект на пакеты и по отдельности пишу их. Т.е. я не пытаюсь писать всё в одном файле.
Притом приоритет отдаю тем вещам, которые необходимы для быстрого запуска, пусть урезанного, почти не работающего, но всё-таки проекта.

doza_and
Как заставить easy_install.exe выкачать нужные мне части на локальный диск?

virtualenv и pip полностью решают эту проблему.

Пакеты - хорошо, а библиотеки - еще лучше. Один раз научились писать setup.py - и нет проблем.

1. Если лень править - добавляем в __init__.py нужные имена (импортом или еще как).
2. Если есть setup.py - инсталляция библиотеки не вызывает проблем. Установка зависимостей - тоже.

Про отладку - не понял. Если есть .pyd с отладочной инфой и прочее счастье - то что еще нужно?
И, эээ, при чем здесь pyscripter?

3. easy_install имеет ключ –find-files. pip, конечно - лучше.

За pip всем большое спасибо буду использовать.
Отладка, винды.

У меня отладка как процесс у бременских музыкантов сверху редактор (pyscripter) ниже процесс интерпретации еще ниже процесс отладки скрипта еще ниже процесс отладки динамической библиотеки.

Если сказать среде разработки (msvc) делать версию pyd с отладочной информацией то в коде swig это приводит к конфигурации ключей которая требует использования отладочной версии python (python_d) с обычным просто не грузится динамическая библиотека. Но с отладочным python_d не грузятся остальные библиотеки - которые не отладочные. Получается сплошное запутывание. Поэтому мне приходится слегка дурить msvc. С обычными dll естественно все нормально никто ведь не знает что там внутри. Это скорее вопрос про опции swig.

По поводу библиотек. Тут наверное мы еще не привыкли. Библиотека общая у нас под svn (как впрочем и большинство библиотек). Если я правильно вас понял то вы предлагаете вместе с svn update,commit делать еще одновременно каждый день update и setup? Да вы наверное, правы надо настроить svn так чтобы он делал setup если произошли изменения. Руки просто до этого не дошли.

отладочный питон обычно не нужен - делайте как сейчас у вас - стандартный питон и pyd с включенной дебаг инфой.
Про pyscripter все же не понял. Редактор - отдельно, а прогу запускать можно из просто так из cmd.exe (или mingw bash, смотря что вы предпочитаете).
Я или цеплялся из Visual Studio к запущенному процессу, или указывал у него в параметрах запуска
python.exe path_to_py <cmd line params>
тогда все заводится из среды по <F5>, когда код дойдет до breakpoint - выпадет в отладчик.

Кстати, а почему swig? Как на мой вкус - самый неудобный способ выстрелить себе в ногу.

До автоматической настройки системы контроля версий на перекомпиляцию я не додумался. Не уверен, что оно будет полезно. Вручную - да, таки делал.

Под питоновской библиотекой мы оба понимаем одно и то же? Нечто с setuptools setup.py, который делает всю работу используя стандартный набор команд (build, install, develop etc)?

Да под библиотеками мы понимаем одно и тоже. Про супер автоматизацию тоже согласен не всегда полезно углубляться. Вопрос в том, что все-таки наверное должен быть один источник обновлений или setup из интернета или svn (bazar) из репозитория.

Отладка запускается обычно из msvc или другой среды для кода нижнего уровня а вместо python.exe path_to_py <cmd line params> делаю pyscripter –python26 example.py <cmd line params> В результате под отладкой получаю среду разработки питона и вней спокойно идет разработка с импортами и прочим. Отладчик нижнего уровня просто тихо спит в углу. А когда доходит до глюков нижнего уровня вот тут он и просыпается.

Если подскажете хорошую альтернативу, сохраняющую прозрачную работу с c++ классами То прибью swig с большим удовольствием. Проблема boost python в том, что когда народ приходит с исходниками от code GEAR (любимая история CBuilder или PASCAL) то прикрутить очень сложно - их компилятор просто никакой. Остальное просто не пробовал.

А при чем тут интернет?
Как я понимаю, обновился разработчик из репозитария. Запустил setup.py на всех библиотеках, которые поменялись.
Когда у нас библиотек было десяток - написал маленький скрипт, который обновлял их по очереди учитывая зависимости.

интернет нужен когда забываешь принести какую-нибдь стороннюю библиотеку. Тут я думаю просто надо мне еще доки почитать как правильно setup делать чтобы не ссылки были а копии библиотек.

Для конечного пользователя setup понятен. А почему вы при разработке просто не прописали дополнительные пути поиска модулей вместо того чтобы писать скрипт и все время его запускать?

Как раз конечный пользователь не должен использовать setup.py
Делайте пакеты для вашего пакетного менеджера (deb, rpm), создавайте инсталлятор с помощью py2exe и inno setup.
setup.py - инструмент только для разработчиков. Нарушение правила дорого обходится в поддержке.

Прописать дополнительные пути - куда? В pth - это же моветон. setup.py develop и так все прекрасно зарегистрирует. Заодно еще и соберет c extensions если нужно. Для автотестов нужно ставить setup install в отдельном virtualenv, пересоздавая окружение каждый раз. Иначе тесты не ловят некоторые досадные проблемы..

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

upd. Возможно, setup develop снимет ваш вопрос по поводу “переустанавливать библиотеку каждый раз”?