@
cnt2ex #63
我的描述是基于自己的记忆和理解，不一定就是正确的。
我原本是想要通过 __all__ 这个例子来体现，基于文件系统的 import path 对今天包管理机制造成的困扰。
在当时 windows/dos/Macintosh 的文件系统上，import * 遍历出来的文件名是大小写不固定的，也就导致了引入的符号表大小写不固定。于是设计了 __all__ 机制，因为 __all__ 定义的大小写是可控的。开发者可以选择 opt in 。
__all__ 机制是需要手动维护的，也不能阻止用户显示地手动引入。如果今天重新设计一门语言，__all__ 是完全不必要的，可以通过 public/private 关键词，也可以通过某种 name convention 来实现。
并不是说基于文件系统的 Package 组织形式不好，而是说这是一个选择。Python 选择了简洁，但是要在别的地方（包管理）付出代价。__all__ 机制就是这个代价之一。
回到虚拟环境的问题上，现在假想一下 Python 依旧使用基于文件系统的 Package 组织形式，但是在路径名中包含版本号。
现在 Python 就面临几种选择，要么以 import xyz==1.1.1 的形式使用，要么 Python 自己实现一个版本选择机制然后维持 import xyz 的向后兼容。
第一种方案几乎没有人选的。因为一旦要升级依赖，需要显示地在源代码里面做修改。但是这个方案的改版非常多见，比如 npm 的 package.json 就是集中把 xyz==1.1.1 放到了一起。
（看起来很完美对吧，但是当时没有人意识到这个 NP 问题会成为日后的麻烦。这种组织方式从机制上就不允许引入同一个包的不同版本，所以 NP 问题退化为 P 问题的途径就少了一个。）
第二种方案，考虑到时间节点，不是一个好的选择。但这个路线是近十年来以软件工程为导向的语言的首选。
这里需要明确区分 Package 的组织形式和 import path 的实现，前者是一种 specification 规范，后者是一个实现方式。Python 完全可以从规范层面要求所有的包名都带版本号，然后 import hook 的实现无视它，固定使用版本号最大或者最小，甚至文件最后修改信息最新或者最旧的版本。
虚拟环境解决的是：在 Package 组织形式是基于文件系统、且 Package 规范不包含版本号的前提下，提供一种在同一个系统中，安装同一个包多个不同版本的可能性。
如果 Package 规范要求包名带版本号，那么“安装”这个行为是不受限制的，也就不需要虚拟环境了。至于安装好了之后，使用时“选择“哪个版本，这是另一个事情。
技术层面上，我猜 Python 转向 npm 类似的包管理方式是没有太大难度的，PEP 621 规范了 pyproject.toml ，也就是前面说的方案一，楼上 frostming 开发的 PDM 就是这么做的。现在的问题是 Python 的 import hook 本身并不支持路径名带版本号的，所以还是需要再套一层虚拟环境，让 Python 只能访问到特定的包。
说得再具体一点，包管理器在文件系统里，以包名+版本号的形式，集中管理所有的包。虚拟环境指定了 $PATH ，在当前环境中的包软链接到实际的带版本号的包，然后软连接的名字不包含版本号。包管理器额外维护一个 pyproject.toml 记录当前所用的包，同时负责计算依赖。在此环境内的 Python 解释器和源码都不需要做任何改变，完全向后兼容。