在Django项目中引入同仓库其他团队开发Python包的最优方案咨询

结合场景，第二种方案（添加setup.py打包后安装引入）是最优选择，理由如下：

• 可维护性更高：不需要在业务代码中硬编码修改sys.path，也不需要对部署环境的PYTHONPATH做额外适配，后续如果other_team_work有版本迭代，直接更新包版本即可，无需调整路径配置。
• 依赖管理更规范：可以将该包的依赖直接写入my_django_project的requirements.txt中，部署、新环境搭建时可以一键安装所有依赖，避免出现漏装依赖、路径配置遗漏导致的导包报错。
• 版本可控：如果后续其他团队对implemented_logic做了变更，你可以通过版本号锁定当前使用的稳定版本，不会因为仓库中other_team_work的代码更新直接影响你的业务逻辑，也方便做版本回滚。

调整PYTHONPATH/sys.path的方案仅适合临时测试场景，生产环境使用会存在大量隐患：比如路径硬编码适配不同环境的成本极高，多人协作时所有开发人员都需要在本地配置相同的环境变量，后续仓库目录调整时所有路径配置都要同步修改，排查导包问题的成本也会大幅提升。

如果采用打包安装方案，基础操作步骤如下：

1. 在other_team_work目录下新增setup.py，基础配置示例：

from setuptools import setup, find_packages

setup(
    name="other_team_work",
    version="0.0.1",
    packages=find_packages(),
    install_requires=[
        # 填写该包依赖的其他第三方库
    ]
)

2. 本地开发时可以在my_django_project的虚拟环境下执行可编辑安装：pip install -e ../../other_team_work，这样other_team_work的代码修改会实时生效，不需要反复重装。
3. 生产部署时可以将打包好的.whl文件上传到内部私有PyPI源，然后在my_django_project的requirements.txt中添加other_team_work==0.0.1即可直接安装。

内容的提问来源于stack exchange，提问作者jaguarpaw