如何处理与公开包名冲突的专有Python包名？
背景
我所在的团队一直在使用和开发一个叫做 foobuilder 的Python包。我们为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 包与 foobuilder 发生冲突。这可能需要用户在过渡期间稍微调整他们的包管理器，但我认为这不是大问题。不过，这样做会阻止用户同时使用公共的 foobuilder 包。
问题
有没有比我上面考虑的方案更简单或更好的处理方式？我考虑的解决方案有什么问题吗？你会怎么处理这个情况？
3 个回答
符号链接？
$ echo "print 'foo'" > foo.py
$ ln -s foo.py bar.py
$ python -c "import foo; import bar"
foo
foo
其实很简单，虽然有点像小技巧 :)
我觉得在这种情况下使用一些临时的解决办法是可以的，只要这个办法是可控的。如果我是你，我会创建一个文件，用一个不同的标识符来表示你的包，比如叫 so.py，然后文件内容是
import relative_pathname/foobuilder as my_foobuilder
这样的话，这个包就可以明确地被称作 so.my_foobuilder，而不需要任何团队去改他们的产品名称。虽然这不是一个完美的解决方案，因为所有内部的内容都需要调整，但这样可以解决冲突，而不需要更多的修复工作。
我建议你给新的foobuilder包的作者发个邮件，讨论一下这个问题。显然，你们其中一个需要更改包的名称; 由于你们程序的专有性质，可能不太想改名字……向新的包作者询问这个问题，可能会得到一些新的解决方案。
其实，没有什么合理的方法能让Python处理这个问题，让'import foobuilder'有两种不同的意思。