python - 如何将 Python 脚本从一个子包移动到另一个目录/包，保持向后兼容性

Question

我有一个共享的 Python 代码库，我负责其他人依赖的代码。我需要将模块从一个子包移动到另一个目录/包以重新组织它。我该如何以最安全的方式做到这一点？

如果我只是移动代码，我必须担心使用它的其他人可能没有重定向他们的导入。如果它被移动并且代码的用户不更改他们的导入，当导入失败时，他们的代码将意外失败。

如何确保无缝过渡？我是否只是复制代码并保留旧代码直到导入已更改？有什么注意事项吗？如果我使用 import * 会怎样结合 __all__ ?在什么情况下，我必须无限期地支持从旧位置导入？

Answer 1

我最近在工作中被要求将代码从一个子包移动到另一个子包，而我使用的方法对其他开发人员来说似乎并不明显，所以我在这里记录下来供其他人使用。
我不建议在旧地方留下副本。如果您有相同脚本的两份副本，其中一份可能会在没有另一份的情况下发生变化。相反，我推荐以下多步骤过程。
第一步涉及两个部分，如果您控制代码的两个位置，则可以同时实现这两个部分。
第一步:实现行动

首先，将文件从旧位置移动到版本控制下的新位置。我使用 CVS 的简化接口(interface)，因此它是一个版本控制副本。在大多数其他版本控制系统(如 mercurial、subversion 和 git)中，您应该使用 mv移动文件，例如使用 git:

 git mv /location/old/script.py /location/new/script.py

重要提示:
不要忘记移动单元测试，还要移动 __init__.py '如果旧代码中有代码需要保留。否则，只需确保提交 __init__.py在那里，如果他们还没有到位或

接下来，在旧代码的位置，从新位置导入所有名称，
所以在 /location/old/script.py :

 from location.new.script import *

并留下评论解释为什么需要这样做，并将更改提交到版本控制。如果您移动了 __init__.py ，只要确保提交一个新的空 __init__.py .

有一个 主要警告 这里。 import *受 __all__ 影响.如果您有 __all__声明，您有两种方法来提供缺失的名称。您可以显式导入它们:

from location.new.script import *
# names not in the new.script's __all__:
from location.new.script import foo, bar, baz 

或者您可以删除文件并在 __init__.py 中导入模块，并像这样添加到 sys.modules 的路径:

from location.new import script
import sys
sys.modules['location.old.script'] = script

此代码将初始化包并将模块添加到 sys.modules正好 catch 进口商在那里查找。这与 os.path 的方式相同在 Python source 中创建.大多数人会回避修改 sys.modules ， 然而。事实上，我犹豫要不要把这个建议留在这里，如果它不在 Python 标准库中，我也不会。
这两个部分可以一起推到生产中，并且这一举措已经无缝实现。如果您无法控制代码的用户，则可能需要无限期地保持原位以实现向后兼容性。
可选:然后我会在头上删除旧脚本(只是在头上，不要推送它!)以便其他开发人员可以看到即将发生的变化并及时解决变化。
第二步:实现引用
如果您可以对依赖于您的代码的所有代码进行正则表达式搜索，我建议您在代码中搜索以下正则表达式:

(import|from).*location\.old.*script

如果您使用的是 Unix(或使用 Cygwin)，您可以对其进行正则表达式搜索:

grep -rEe "(import|from).*location\.old.*script" .

或者大多数 IDE 都有正则表达式搜索。
如果您确实可以控制使用它的代码，或者您对使用它的其他人有看法，那么将导入从旧的更改为新的非常简单，例如从 :

import location.old.script

到

import location.new.script

并从

from location.old import script

到

from location.new import script 

等等。
重要提示:
所有这些更改都需要实现并发布到生产环境中。如果在没有完成这些操作的情况下仍有任何生产安装，如果您删除旧位置，它们将失败。
第三步:删除生产中的旧脚本
这是危险的一步。如果您错过了任何用户/导入者，他们的代码将失败，直到他们将导入修复投入生产。您可以选择无限期地推迟这一步，但我更喜欢及时完成，前提是我能证明所有更改都已投入生产。
如果您在进行更改后立即将其删除，以便其他人可以看到正在开发中的更改，那么您可能不必担心。
尽管如此，在您可以证明没有其他用户正在引用生产中的旧包位置之前，请不要删除它。如果你不能证明它，不要删除它。