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

Question

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

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

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

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

Answer 1

Я хотел упомянуть, что решение, которое я рассмотрел перед тем, как спросить, было установить Pinax PyPI и сделать для него релизы для разработки. Мы могли бы установить экземпляр епископа. Мы уже используем pip -find-links для указания на 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. Затем управляйте всеми необходимыми изменениями с помощью диспетчера исправлений, например quilt или Mercurial's Queues . Затем объедините каждый внешний пакет с любыми примененными исправлениями в согласованном формате. Или укажите URL-адреса базовых пакетов и URL-адреса отдельных исправлений и примените их во время установки. По сути, это то, что MacPorts делает.

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

Answer 4

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

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

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

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

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