这是所有开发人员都害怕的事情：发布一个你维护的包的版本，却发现这个构建被破坏了，或者有一个严重的错误。你的第一反应可能是从PyPI中删除这个版本，事实上，PyPI的界面让它变得很容易，仅在2019年就有数百名开发人员这样做了。但是——除非出现异常情况，如包含恶意代码或安装步骤会抹掉用户的计算机的内容——否则你应该抵制这种冲动，以免破坏用户的构建。越来越多的用户，尤其是更大的组织，倾向于通过“冻结”依赖关系，将每个依赖关系固定在特定的版本上，以实现可复制的构建。删除发行版时，会破坏锁定该发行版的任何项目的构建。PyDist维护已删除版本的提要，以跟踪此问题。在过去的6个月中，已有超过10，000个被删除，这促使PyDist为其用户做PyPI的镜像。发布坏版本后要做什么如果您发布了一个引入恶意代码的版本，或者这将导致立即和不可逆转的损害，那么请务必从PyPI中删除该版本(并与他们联系，让文件从他们的CDN中实际删除，这样他们就可以与PyDist这样的镜像联系)。否则，最好的做法是采用最新的“好”版本，并将其重新发布，作为对坏版本的修补。这样，像pip这样的工具就不会安装坏版本，除非他们得到了特别的指示。与此同时，任何锁定了坏版本的人仍然能够成功地安装它，并且很有可能在下次冻结他们的依赖关系时很快升级到“好”版本。发布糟糕的版本后，沟通也是关键。在GitHub或您选择的bug跟踪器上打开一个问题，并在变更日志中添加一个不应该使用某个版本的通知。如果你有邮件列表，也在那里发布公告。绝对不要为了重新上传一个固定版本而删除一个版本！PyPI不允许您重新上传同名文件，这对许多尝试过这种方法的维护者来说是一个令人讨厌的惊喜。因为轮子的文件名决定了pip如何对待它，所以在上传之前你不能通过重命名你的工作来回避这个问题。当某人删除了您所依赖的版本后，该怎么办？首先，让我强调不要做什么：攻击GitHub、推特或其他任何地方的维护者。记住你一直免费使用他们的作品。您的首要任务应该是解除构建，这通常可以通过锁定你的requirements.txt、Pipfile或pyproject.toml中的违规包的早期版本来解决。如果许多版本已经被删除或者最终导致依赖冲突，您可能必须采取更严厉的措施：在您的机器的pip轮缓存(~/)中找到轮的副本。unix上的缓存/pip/wheels ),并使用pip安装直接安装文件。这可能与您的依赖管理系统不太协调，所以您可能需要暂时绕过它。在那之后，你可能想联系维护人员，找出发生了什么，并建议删除一个版本的未来替代方案——记住，他们可能刚刚从其他用户那里收到一堆愤怒的评论。我与GitHub上的维护者进行了积极的互动，评论如下：首先，感谢@<maintainer> for maintaining <package>。这是一个很棒的库，在过去几年里我已经在多个项目中使用过了。不过，我确实认为从PyPI中删除一个版本是错误的。当你第一次意识到一个发布被破坏了，它看起来就像一场灾难。但是许多安装您的软件包的人并不使用它，通常只是间接地将它作为对其他软件包的依赖而导入，并且可能不会受到版本中任何损坏的影响。如果他们锁定了包版本(像大多数试图避免破坏的组织一样)，删除一个发行版肯定会破坏它们。依我看，最好的办法是立即重新发布以前的版本，作为对损坏版本的修补。然后，没有谁还没有安装坏版本将安装它，你可以在你的闲暇时间里再发布一个修补版本。但是最终，维护者可能不会同意，或者它可能会发生在你的另一个包中。如果这种情况重复发生，您可能希望开始使用PyPI镜像。当然，我建议使用PyDist，但是也有很好的自我托管选项，比如devpi。作者：Alex Becker