Как бороться с запатентованным именем пакета Python, конфликтующим с публичным?

Question

Фон

Группа, с которой я работаю, использует и разрабатывает пакет Python, который для целей этого вопроса я назову foobuilder. Мы обслуживаем обновления для систем Linux, используя частные RPM и Deb-репозитории, которые мы предоставляем нашим пользователям.

Недавно в PyPi был добавлен публичный пакет с тем же именем. Он также был упакован в общедоступном репозитории Debian, среди других мест. Поскольку мы публично не рекламируем нашу посылку, понятно, что посылка с тем же именем всплыла.

Беспокойство

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

Помимо очевидной проблемы в Python, я бы предположил, что добавление нашего репозитория в программу менеджера пакетов Debian также может вызвать некоторые проблемы, хотя я еще не играл с этой ситуацией.

Задача

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

Мои мысли о возможных решениях

Python

Я рассмотрел вопрос об изменении имени пакета на my_foobuilder и включил в него метапакет под названием foobuilder, который состоит только из __init__.py, который импортирует все из my_foobuilder. Я мог бы поручить новым пользователям импортировать my_foobuilder напрямую. Тогда я мог бы начать осудить имя foobuilder. В конце концов, это приведет к тому же объему работы, как если бы я изменил foobuilder на my_foobuilder сейчас, поскольку все должны получать обновления, а имя foobuilder не может оставаться в чистилище устаревших навсегда.

Debian

Проблема Debian не должна быть слишком сложной для решения; Я могу изменить имя пакета debian на my_foobuilder, но он по-прежнему должен устанавливать тот же (конфликтующий) пакет Python. Затем я мог бы установить пакет my_foobuilder на Conflict с foobuilder. Может потребоваться, чтобы пользователи возились со своим менеджером пакетов, чтобы вернуть вещи в нужное русло во время перехода, но я не думаю, что это имеет большое значение. Тем не менее, это не позволяет пользователям одновременно использовать общедоступный пакет foobuilder.

Вопрос

Есть ли более простой или лучший способ справиться с этой ситуацией, чем я рассмотрел выше? Есть ли проблемы с решениями, которые я рассматриваю? Как бы вы справились с этим?

Answer 1

Я бы напишите новому автору пакета foobuilder, чтобы обсудить проблему. Очевидно, один из вас должен изменить имя пакета ; Из-за запатентованного характера вашей программы может быть нежелательно менять ее название ... Задавая этот вопрос новому пакету, автор может предложить несколько новых решений.

На самом деле нет здравого смысла, чтобы Python обрабатывал это так, чтобы «import foobuilder» мог означать 2 вещи.

Answer 2

Symlinks

$ echo "print 'foo'" > foo.py
$ ln -s foo.py bar.py
$ python -c "import foo; import bar"
foo
foo

Очень просто, хотя и хакерски :)

Answer 3

Я думаю, что использование клуджа здесь было бы хорошо, если бы он контролировался. Если бы я был в вашей ситуации, я бы создал файл с некоторым другим идентификатором для вашего пакета, например so.py, и имел бы содержимое

import relative_pathname/foobuilder as my_foobuilder

Тогда на пакет можно однозначно ссылаться как so.my_foobuilder, не требуя от какой-либо команды смены названия продукта. Это не очень хорошее решение, поскольку все внутренние компоненты должны быть сдвинуты, но это должно разрешить конфликт, не требуя дополнительного исправления.