是时候告别setup.py的复杂性，拥抱使用构建前端实现高效Python打包。
在本文中，我们将探讨distutils和setuptools面临的挑战，以及为什么直接调用setup.py不再是最佳方法。Distutils和Setuptools曾经非常重要，但是在直接使用setup.py时它们都面临着一些限制。Distutils缺乏现代化的功能，而setuptools引入了复杂性和可移植性的挑战。
改变了自己的方法，setuptools团队正在逐渐放弃提供命令行界面，而是专注于成为创建软件包的库。这个变化并不意味着setuptools被废弃，而是应该避免直接执行setup.py文件。
使用像pip或Poetry这样的依赖管理工具可以实现自动化的软件包构建和安装过程。拥抱其简单性、可移植性和未来性的好处，使它们成为现代Python打包的关键。
传统上，setup.py作为进入Python打包世界的入口点。开发人员依赖它来定义项目的元数据、依赖关系和安装说明。脚本的调用就像运行python setup.py install一样简单明了，似乎是打包Python项目的事实标准方法。
然而，故事并不止于此。个人经历经常揭示出仅仅依赖于setup.py的限制和怪癖。像许多开发人员一样，当我在一个使用distutils和setuptools的项目上工作时，我发现自己陷入了一个令人困惑的依赖冲突和版本不兼容性的困境中。当一个库更新触发了一连串意外错误时，感觉像是在追逐幻影。
想象一下你正在构建一个名为“my_package”的软件包，其中包含一个简单的模块“my_module.py”。在过去，你的打包过程可能看起来像这样：
# setup.pyfrom distutils.core import setup
setup( name='my_package', version='1.0', py_modules=['my_module'], # Other metadata...)看起来很简单，对吧？但是随着项目的复杂性增加，distutils显示出了它的局限性，这种方法缺乏许多高级功能，如依赖管理和自动安装。
Setuptools以其先进的功能和依赖管理的承诺一炮而红。setuptools是对distutils的改进，但是甚至它也正在被更现代的打包工具所取代。
假设你有一个更复杂的项目，需要外部依赖和额外的元数据：
# setup.pyfrom setuptools import setup
setup( name='my_package', version='1.0', packages=['my_package'], install_requires=[ 'requests', 'numpy', ], # Other metadata...)Setuptools最初通过简化的软件包分发、依赖管理和元数据增强功能改进了Python开发。运行python setup.py sdist会为distutils和setuptools创建一个源代码分发。然而，随着Python的发展，一些限制也出现了：
- 全局安装冲突：Setuptools通过全局安装不同的依赖版本导致冲突，从而在项目之间引发兼容性问题。
- 复杂性和可维护性：随着项目的增长，管理setup.py文件变得复杂，需要跨项目进行更新，从而降低了开发速度。
- 隔离和可重现性：Setuptools难以隔离项目依赖关系，使得在不同系统上实现一致的环境变得困难。
- 缺乏标准化：Setuptools缺乏标准化的项目结构或配置格式，导致项目组织上的碎片化。
然而，setuptools一个明显的缺点是在处理不同平台和环境下的依赖解析时存在不一致性。这种不一致性经常导致在不同系统上尝试安装软件包时出现挑战。为了解决这些问题，一个替代的方法是使用构建前端和后端。
传统方法（如setuptools）所带来的挑战引发了PEP 518和PEP 517的引入，以及pyproject.toml文件的采用。PEP 518和PEP 517带来了一个值得注意的进展：构建前端和后端的分离。这使得开发人员可以根据需要轻松切换构建工具。例如，用于本地开发、测试或生产构建的不同工具。
不再需要筛选混乱的 setup.py 文件，您可以在一个集中的地方管理项目的配置、依赖和构建设置，即 pyproject.toml 文件。这个单个文件成为您的指挥中心，使项目的管理变得轻松。
[tool.poetry]name = "my_package"version = "1.0"[tool.poetry.dependencies]python = "^3.6"requests = "^2.25"numpy = "^1.20"[build-system]requires = ["poetry-core>=1.0.0"]build-backend = "poetry.core.masonry.api"在这里，配置被整理得井井有条且表达清晰。依赖项使用版本范围进行定义，既灵活又确保兼容性。 [build-system] 部分是魔法发生的地方。 [tool.poetry] 部分定义了项目的元数据和依赖项，而 [build-system] 部分指定了构建后端，负责执行构建过程。
当您准备构建您的软件包时，只需要执行命令 ’poetry build’。
Python 打包工具的发展历程非常有意思。过去，distutils 和 setuptools 是主流，尽力满足当时的需求。但随着软件开发的世界发展，它们发现自己有些力不从心了。
Poetry 不仅仅简化了复杂的依赖关系，它就像是加固了您项目的核心。可以将其想象为增加了一层韧性的额外保障，使您的项目更加强大和面向未来。
因此，请记住，虽然 distutils 和 setuptools 是它们时代的明星，但现在的舞台属于 poetry 及其伙伴们！
感谢您的阅读！希望您觉得这篇文章有帮助。如果您想了解更多信息，请查看 作为本讨论基石的文章 。您也可以在 LinkedIn 或 VoAGI 上关注我，以获取我最新的工作动态。
下次再见，Anushka！