Как лучше всего организовать и разработать проект, состоящий из множества небольших скриптов, использующих одну (или несколько) более крупных библиотек Python?
В нашем репозитории есть несколько программ, которые используют одни и те же библиотеки, хранящиеся в одном репозитории. Другими словами, макет вроде
trunk
libs
python
utilities
projects
projA
projB
Когда официальные запуски наших программ будут завершены, мы хотим записать, какая версия кода использовалась. Для наших исполняемых файлов C ++ все просто, потому что, пока рабочая копия чиста во время компиляции, все в порядке. (А поскольку номер версии мы получаем программно, это должна быть рабочая копия, а не экспорт.) Для скриптов Python все сложнее.
Проблема в том, что часто будет запущен один проект (например, projA), и projB необходимо будет обновить. Это может привести к тому, что ревизия рабочей копии будет выглядеть смешанной для projA во время выполнения. (Для выполнения кода требуются часы, и его можно использовать в качестве входных данных для процессов, выполнение которых занимает несколько дней, отсюда и сильная цель отслеживания.)
Мой текущий обходной путь - при необходимости проверить еще одну копию ствола в другом месте и убежать оттуда. Но тогда мне нужно не забыть изменить свой PYTHONPATH, чтобы он указывал на вторую версию lib / python, а не на ту, что находится в первом дереве.
Вряд ли будет идеальный ответ. Но должен быть способ получше.
Должны ли мы использовать ключевые слова Subversion для хранения номера версии, что позволит пользователю данных экспортировать файлы? Должны ли мы использовать virtualenv? Следует ли нам больше подходить к механизму упаковки и установки? Setuptools является стандартом, но я читал о нем разные вещи, и, похоже, он предназначен для конечных пользователей, не являющихся разработчиками (которых у нас нет).
