@kuanat #64

> 如果 Package 规范要求包名带版本号，那么“安装”这个行为是不受限制的，也就不需要虚拟环境了。至于安装好了之后，使用时“选择“哪个版本，这是另一个事情。
所以我对“如果 Python 决定重写 import hook ，将版本号纳入成为包名的一部分，支持安装同一个包的多个版本，就没有今天虚拟环境什么事了”这句话产生疑问。
无论怎么重写 import hook ，又或者在包里加上版本区分。仅仅是在“被导入方”加入版本信息还不够，还需要在“导入方”记录要导入的版本才行。
脚本型语言和编译型语言不一样，不存在编译、运行两个过程，编译型语言可以在编译时，在二进制文件里记录版本信息，那脚本型语言在哪里记录版本号就是个问题了。

> Python 完全可以从规范层面要求所有的包名都带版本号，然后 import hook 的实现无视它，固定使用版本号最大或者最小，甚至文件最后修改信息最新或者最旧的版本。
你所说的几种情况，一旦某个依赖的包升级，就有可能导致已有项目崩溃。且不说 lib.py.1.0 被 lib.py.2.0 取代，会导致依赖 lib.py.1.0 的项目崩溃。
即使只是 lib.py.1.0.1 被 lib.py.1.0.1 取代，这种崩溃也是可能的，semver 无法解决这个问题。因为很多时候你无法区分 breaking, enhancement 和 bugfix 。
用别人的例子， [你在你的包里加入了一个 warning ，这个是属于 breaking, enhancement 还是 bugfix ？]( https://twitter.com/brettsky/status/1262077534797041665)
这里选择 bugfix 的是最多的，可你又如何保证你新输出的 warning message 不会 break 别人的项目呢？所以 semver 本身是无法被依赖的。你无论再怎么设计规范，总会出现你的 bugfix 成为别人的 breaking 的情况。

其实我想说的重点是，多版本共存本身不是问题所在。反而由于如果强行多版本共存，在运行时，要如何“选择”哪个版本是主要问题。而为了解决这些问题，又进一步会带来一堆问题。

所以，为什么非要多版本共存？没有多版本共存本身就是一种解决方案，而不是问题。

@kuanat #58

我的疑问是，__all__和你提到的文件系统大小写敏感几乎没有关系。因为解决大小写不敏感所带来的问题的方案主要是通过规范要求名称都是小写。而且不管有没有__all__，import *都可以使用，只不过没有__all__会默认导入所有非下划线开头的名字。但正是这一点，让我很疑惑为什么要扯上__all__。也许你提这个目的单纯是想说__all__的诞生的历史是在规范模块名之后提出的？除此之外我看不出__all__和文件系统大小写不敏感有什么关系。

正是前面这一点我没看懂，所以之前还有一点也没继续问下去。其实还有一个问题就是，你#48 提到：
> 这个时间点上，如果 Python 决定重写 import hook ，将版本号纳入成为包名的一部分，支持安装同一个包的多个版本，就没有今天虚拟环境什么事了。
为什么这样能解决需要虚拟环境的问题？按我所理解的，go 之所以能把所有 mod 都哦下载到$GOPATH/pkg 下，然后在加上版本区分，完全是因为二进制文件能够记录编译时的版本号（说的更完整一些，完全也可以静态编译）。

而对于脚本型的语言，没有一个地方记录库对应的版本，因此这类语言采取的方式都是设置对应的 PATH （比如 PYTHONPATH 等等），然后在 PATH 中寻找最先遇到的库的版本导入。如果你要多版本共存，在同一个 PATH 下，遇到同个包的两个版本，该导入哪个？

@kuanat
> 为什么 Python 需要 __all__ 来支持 from XXX import *
__all__不是拿来指定哪些是公开接口，哪些不是吗？你给出的回答似乎和为什么需要__all__没什么关系？？？

还有所谓多版本共存的问题，这不是真正的问题所在。

对于编译型的语言，编译（链接）时，会在生成的可执行的文件里记录对应的版本号。在运行时，则会根据可执行文件中记录的版本去动态链接对应的库。这里的多版本库的共存的机制其实不是语言本身的，而是 ELF 文件格式提供的（以 linux 为例，windows 应该也有类似的机制）。

但对于脚本型语言，你的脚本里没有记录依赖的库版本（并且也不该在代码级别处理版本依赖）。
因此即使你在安装的库的版本里，加了版本后缀作为区分又有什么用呢？因为你脚本本身没有记录到底使用的哪个版本。

python 的虚拟环境和其他语言的依赖管理工具是类似的，解决都是依赖管理和隔离的问题。

pip 安装包时，把包安装在了系统/用户路径。而不同项目使用同一个系统/用户路径就会有依赖冲突的问题。所以有了虚拟环境这个概念，来隔离不同项目使用的不同版本的依赖。

而其他语言的工具链可以直接把包安装到当前项目的路径，然后当前项目的库路径加入到库加载路径里（比如 CLASSPATH ）。因此这些语言没有虚拟环境这个概念。

实际上楼上也有人提到了，python 其实也可以学习这个做法，把所有包安装到项目的目录下，然后设置 PYTHONPATH 。

光从排列组合的数量来讲，并不是能允许的密码数量越多越就越安全。

一个禁止 123456 和 654321 的系统会比不禁止的安全，因为这两密码太常用了。

Windows 10 IoT Enterprise LTSC 2021
一直支持到 2032

按照官方文档给的步骤更新就是了。

上游在打包的时候，自然会控制不同版本的仓库间的包不会出现太大的跨度。比如某个包从 v1 升级到 v2 ，这种升级一般都不会出太大的问题。

滚动更新是因为根本无法预测到底是从哪个版本升级到哪个版本，所以长时间不更新后再次更新，从 v1 一下升级到 v10 （只是据个例子，现实不一定会遇到），遇到复杂的依赖问题，自然容易滚挂。

对于旧包，很多包管理器都提供清理不再需要的依赖的功能（比如 apt autoremove ），或者清理旧版本仓库中存在的包，但是新版本仓库已经移除的包（ aptitude purge '~o'）

@zizon 试了一下，好像符号链接就行，虽然每次从其他机器 pull 都要手动创建符号链接。

@CivAx 你说的收邮件那更是另外一回事了。也是需要域名所有者设置 mx 记录到 mailgun 的邮件服务器，从而 mailgun 能接收邮件，再给你 route 到 outlook 。

如果你要收第三方邮箱的信件，要么通过 IMAP/POP 用户名密码读取对应的邮箱，要么设置 mx 记录从而域名下所有邮件都发到你这里。这都是需要第三方参于的。
而发邮件的逻辑却是直接采用了伪造发信者的方法。正是从收发邮件的逻辑来比较，我认为发邮件允许用户随意伪装所存在的不合理的地方。

@CivAx 这个特性和 mailgun 、amazonses 之类的邮件服务是两码事吧。

mailgun 之类的服务，通常是通过域名所有者设置对应的 SPF/DKIM/DMARC 记录来完成，并且收发邮件时接收方也可以验证。

比如接入 mailgun 这类服务提供商，通常是把子域名解析到第三方的 SPF/DKIM ，并且把 DMARC 记录里 aspf 和 adkim 设置为 relaxed ，从而允许子域名可以作为根域名通过检查。这样 mailgun 则可以通过子域名代发邮件，收件人也可以通过验证子域名的 SPF 和 DKIM 签名来验证。

类似的，包括前面有人提到的同个部门之间可以相互代发，如果子域名和根域名本身就属于同个实体控制下的，所以允许他们相互代发很正常。

但是 outlook 这种是直接修改 From 成另外一个域名，这完全是任何一个邮件伪造者的做法。