Запихивать весь код в один модуль — не лучшая идея. Хорошим примером причины является случай, когда один из ваших экспериментов зависит от двух модулей с разными определениями для одного и того же имени функции. С отдельными модулями ваш код легко различает их; чтобы поместить их в один и тот же модуль, редактор должен был бы сделать какое-то хакерское переименование функций (например, добавить к ним старое имя модуля или что-то в этом роде), и ситуация становится еще хуже, если какая-то другая функция в модуле вызывает ту, с конфликтующим названием. Для этого вам фактически необходимо полностью заменить механизм области видимости модуля.
Составление списка зависимостей модулей также является нетривиальной задачей. Рассмотрите возможность проведения эксперимента, который зависит от модуля, зависящего от numpy. Вы почти наверняка хотите, чтобы ваши конечные пользователи фактически установили пакет numpy, а не связали его, поэтому теперь редактор должен иметь какой-то способ различать, какие модули включать, а какие вы ожидаете установить каким-то другим способом. Кроме того, вы должны учитывать такие вещи, как когда функция импортирует модуль в строке, а не в верхней части вашего модуля, и другие необычные случаи.
Вы слишком многого требуете от своего редактора. У вас действительно две проблемы:
- Отделите экспериментальный код от кода, готового к выпуску.
- Упакуйте свой стабильный код.
Разделение вашего экспериментального кода
Управление версиями — это решение вашей первой проблемы. Это позволит вам создать любой экспериментальный код на вашем локальном компьютере, и пока вы его не зафиксируете, вы не будете загрязнять свою кодовую базу экспериментальным кодом. Если вы действительно хотите зафиксировать этот код для резервного копирования, отслеживания или обмена, вы можете использовать ветвление здесь. Определите ветку как свою стабильную ветку (обычно это магистраль в SVN и master в git) и отправляйте только экспериментальный код в другие ветки. Затем вы можете объединить ветки экспериментальных функций со стабильной веткой, когда они станут достаточно зрелыми для публикации. Такая конфигурация ветвления имеет дополнительное преимущество, позволяя вам отделить ваши эксперименты друг от друга, если вы того пожелаете.
Система управления исходным кодом, размещенная на сервере, как правило, делает все проще и безопаснее, но если вы единственный разработчик, вы все равно можете использовать git локально без сервера. Репозиторий, размещенный на сервере, также упрощает координацию с другими, если вы не единственный разработчик.
Упаковка вашего стабильного кода
Один очень простой вариант — просто попросить пользователей проверить стабильную ветку из репозитория. Распространение таким способом далеко не неслыханно. Это все еще немного лучше, чем ваша текущая ситуация, поскольку вам больше не нужно вручную собирать все ваши файлы; однако вам может понадобиться немного документации. В качестве альтернативы вы можете использовать встроенную функцию управления версиями, чтобы проверить всю фиксацию в виде zip-файла или аналогичного (export
в SVN и archive
в git), если вы не хотите делать свой репозиторий общедоступным; они могут быть загружены в любом месте.
Если этого кажется недостаточно, и вы можете сэкономить время прямо сейчас, setuptools, вероятно, является хорошим решением этой проблемы. Это позволит вам сгенерировать колесо, содержащее ваш стабильный код. У вас может быть сценарий setup.py
для каждого пакета кода, который вы хотите выпустить; сценарий setup.py
определит, какие пакеты и модули следует включить. Вы должны управлять этим сценарием вручную, но если вы настроите его так, чтобы он включал целые пакеты и каталоги, а затем установили хорошие проектные соглашения для организации вашего кода, вам не придется изменять его слишком часто. Это также дает вашим конечным пользователям стандартный механизм установки вашего кода. Вы даже можете опубликовать его на PyPI, если хотите широко распространить его.
Если вы дойдете до использования инструментов настройки, вы также можете рассмотреть возможность использования сервера сборки, который может отслеживать новые коммиты и запускать сценарии для переупаковки и потенциальной публикации вашего кода.
person
jpmc26
schedule
17.04.2017
from mymodule import func
и не используете глобальные переменные и не дублируете имена функций, то, вероятно, вы могли бы безопасно собрать все функции в один скрипт. Если вы обычно используетеimport mymodule
, а затемmymodule.func()
, тогда вы можете настроить сценарий для создания версий оболочки каждого модуля только с соответствующими функциями. - person Matthias Fripp   schedule 23.04.2017