Как я могу работать с разрабатываемыми версиями пакетов Python, не полагаясь на SCM?

Question

Одна из проблем, которая возникает во время разработки Pinax, связана с разрабатываемыми версиями внешних приложений.Я пытаюсь найти решение, не требующее использования систем контроля версий.Причина в том, что я бы предпочел не устанавливать все возможные системы контроля версий в своей системе (или навязывать это участникам) и решать проблемы, которые могут возникнуть во время создания среды.

Возьмем следующую ситуацию (для понимания будет полезно знать, как работает Pinax):

Мы начинаем разработку новой версии Pinax.В предыдущей версии был файл требований pip с явным набором версий.Во внешнем приложении возникла ошибка, которую мы хотели бы устранить.Чтобы исправить эту ошибку в Pinax, текущий процесс заключается в простом выпуске минорной версии приложения, при условии, что мы контролируем приложение.Приложения, которые мы не контролируем, мы просто занимаемся циклом выпуска автора приложения или заставляем его выпускать релизы ;-) Я не слишком люблю постоянно делать второстепенные выпуски для исправления ошибок, как в некоторых случаях мне бы хотелось. также работаем над новыми функциями для приложений.Конечно, мы делаем ветвление старой версии, а затем выполняем резервное копирование по мере необходимости.

Мне бы хотелось услышать некоторые мысли по этому поводу.

Answer 1

Я хотел упомянуть, что решение, которое я рассматривал перед тем, как спросить, заключалось в установке Pinax PyPI и выпуске на нем разрабатываемых версий.Мы могли бы установить экземпляр chishop.Мы уже используем --find-links pip, чтобы указать на pypi.pinaxproject.com для пакетов, которые нам пришлось выпустить самостоятельно.

Answer 2

Не могли бы вы справиться с этим, используя спецификатор версии «==dev»?Если страница дистрибутива в PyPI содержит ссылку на .tgz текущей версии dev (например, github и bitbucket предоставляют автоматически) и вы добавляете к ссылке «#egg=project_name-dev», и easy_install, и pip будут использовать ее. .tgz, если запрашивается ==dev.

Это не позволяет вам указать что-то более конкретное, кроме «последней подсказки/головки», но во многих случаях этого может быть достаточно?

Answer 3

Большинство дистрибьюторов с открытым исходным кодом (Debian, Ubuntu, MacPorts и др.) используют тот или иной механизм управления исправлениями.Итак, что-то вроде:импортируйте базовый исходный код для каждого пакета в том виде, в котором он выпущен, в виде tar-шара или моментального снимка SCM.Затем внесите необходимые изменения поверх него с помощью менеджера исправлений, например одеяло или Очереди Mercurial.Затем объедините каждый внешний пакет со всеми примененными исправлениями в единообразном формате.Или иметь URL-адреса базовых пакетов и URL-адреса отдельных исправлений и применять их во время установки.Это, по сути, то, что МакПортс делает.

РЕДАКТИРОВАТЬ:Чтобы сделать еще один шаг вперед, вы можете затем управлять версиями набора исправлений для всех внешних пакетов и сделать что доступен как единое целое.Это довольно легко сделать с помощью Mercurial Queues.Затем вы упростили проблему и просто опубликовали один набор исправлений с использованием одной системы SCM, при этом исправления применялись локально, как указано выше, или были доступны разработчикам для извлечения и применения к своим копиям пакетов базового выпуска.

Answer 4

РЕДАКТИРОВАТЬ:Я не уверен, что правильно прочитал ваш вопрос, поэтому нижеследующее может не дать прямого ответа на ваш вопрос.

Я рассматривал, но не тестировал, возможность использования функции заморозки пакета pip.Возможно, использование этого и распространение пакета с Pinax сработает?Меня беспокоит только то, как обрабатываются разные ОС.Например, я никогда не использовал pip в Windows, поэтому не знаю, как там будет взаимодействовать пакет.

Основная идея, которую я надеюсь реализовать, заключается в создании скрипта paver, который контролирует управление пакетами, упрощая пользователям обновление до более новых версий.Однако для этого потребуется немного строительных лесов.

Еще одним вариантом может быть сохранение зеркала приложений, которые вы не контролируете, в согласованной виртуальной машине, а затем распространение зеркальных версий.Это избавит «всех» от необходимости устанавливать множество различных программ.

Кроме этого, кажется, что единственное реальное решение - это то, что вы, ребята, делаете, я не смог найти простого способа.