完全免费！GitHub发布软件包管理服务：NPM瑟瑟发抖

本文经AI新媒体量子位（公众号ID:QbitAI）授权转载，完全务转载请联系出处。免费　

GitHub 发布了全新的发布发抖软件包管理服务，叫GitHub Package Registry，软件完全免费。包管

　　有了它，理服用户可以把自己的瑟瑟软件包传上 GitHub，就像发布源码那样。完全务

　　官方介绍说，免费这项服务和NPM、发布发抖Maven等许多现有的软件包管理器都兼容。并且，包管今后还会支持更多。理服

　　消息一出，瑟瑟网友纷纷感受到了一统天下的完全务趋势。

　　有人表示开心：

　　“好事啊，我现在同时用着好几个包管理器，都能放到一起来搞的话，真是诱人。”

　　也有不少人担心：

　　“我的 NPM 是不是药丸？”“看到 GitHub 垄断就不高兴。”

　　那么，这到底是一项怎样的服务？会给包管理工具的世界，源码库带来怎样的震荡？

　　大一统的包管理服务

　　首先，Package Registry 是和 GitHub 完全集成起来的。所以，搜索、浏览、管理工具都和从前没差别。

　　软件包可以和源码并肩发布，也可以使用和源码一样的权限。

　　团队说，下载快速稳定，是由 GitHub 全球 CDN 加持的。

　　现在，来具体介绍一下。

　　都有什么功能

　　在 Package Registry 上，你可以迅速查找公开的软件包，或者你团队内部的私有软件包。

　　它兼容了许多包管理应用兼容，所以可以自由选择工具，来发布自己的软件包：

　　JavaScript (npm) ，Java (Maven) ，Ruby (RubyGems) ，.Net (NuGet) 以及 Docker images 都支持。未来还会支持更多，亿华云比如 Python 已经在路上了。

　　△ 网友焦急：下个支持 Go 啊

　　GitHub 说，如果你的 repo 很复杂，可以发布成好几个不同类型的软件包。

　　以及，通过 webhooks 或者 GitHub Actions，能够完全定制发布中和发布后的 Workflow。

　　软件可以发布成私有，也可以公开：

　　大多数开源项目，源码都在 GitHub 上。可以把预发行版本 (Prerelease Versions) 的软件包公布出来，在社区里做测试，也可以把某个版本放到公开的 Registry 里去。

　　统一的身份和权限

　　如果，你用了许多不同的系统来发布代码和软件包，那就需要许多套不同的 (身份认证用的) 用户凭据和权限。

　　但现在在 GitHub 上，代码和包可以用一套用户凭据，也可以用同样的工具来管理访问权限。

　　GitHub 上的软件包，延用了 Repo 的可见性 (Visibility) 和权限 (Permissions) ，云服务器这样团队就不用再跨系统去维护一个单独的 Registry，以及镜像的权限了。

　　详细信息，知己知彼

　　GitHub 上托管的软件包，都有详细信息、下载统计，以及完整的历史记录可以查看。

　　用户能明晰地了解包里都有些什么。这样一来，就更容易找到适合自己的依赖项。

　　而包的主人查看数据统计，便可以详细了解，其他人/其他项目都是怎样使用了自己的软件包。

　　你要试试么

　　现在，测试版已经上线了。

　　注册一下就可以用：

https://github.com/features/package-registry/signup

　　GitHub Package Resgistry 是免费的。不过，团队也在周围开发一些附加功能，比如针对安全性 (Security) 和合规性 (Compliance) ，打算日后为商业用户提供。

　　要变天了

　　软件包管理器，在开发者的世界里举足轻重。它们整合了自动安装、配制、卸载、升级等等各种环节的工具。

　　比如，在开发应用的过程中，可能用到许多别人写的软件包。有了包管理器，就可以直接安装软件包，省去繁复的搜索、下载代码、解压……这一系列步骤。

　　如今，软件包管理系统百花齐放。不同的开发环境，都有自己的包管理器。

　　每个管理器，有各自忠实的用户。在 GitHub 发布了“大一统”的服务之后，他们都十分关心这些管理器的将来。

　　比如，Maven Central就是一个重量级仓库。

　　Hacker News 评论区的顶楼说，Package Registry 出现了，表示 Maven 就要死了。

　　他还说，自己内心百感交集：

一方面，这个库已经免费存在了很长时间，心生感激。

但另一方面，Key Registries 非常缓慢，几个小时才能拿到自己的 Private Key。除此之外，开发用服务器 (Staging Server) 也很缓慢，总是超时。

而 GitHub 的新服务，是把 Registry 和存储 (Artifact Storage) 分开的。

这样是对的，因为Registry需要快速更新。而存储就在我自己的控制范围了。

　　另外，NPM 的用户也在担心它的命运：

这个服务，可以解决 NPM 的信任问题：你永远不会知道，自己下载的这个包，来源是不是真像页面上写的那样。

　　毕竟，NPM 现在内外交困：

NPM 这巨大的 Registry 人见人爱，可是已经快花光投资人的钱了，靠着私有 Registry 产品支撑。现在，又换了个奇怪的 CEO，投资人的耐心可能要消磨殆尽了。

　　不过，即便 GitHub 服务强势来袭，依然有许多人保持怀疑的态度。比如：

兼容的意思是，两边的 Registry 可以一起用么？那如果名称冲突了怎么办呢？

　　有人回复了这条评论：

这才是真正的问题所在，可能对 JS 的生态系造成严重的破坏。要看 GitHub 怎么处理了。