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

Фон

В группе, с которой я работаю, был использован и разработан пакет 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 одновременно.

Вопрос

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

Ответ 1

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

На самом деле нет разумного способа управления Python таким образом, чтобы "import foobuilder" мог означать две вещи.

Ответ 2

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

import relative_pathname/foobuilder as my_foobuilder

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

Ответ 3

Symlinks?

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

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