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

包栗子 发自 凹非寺

量子位 出品 | 公众号 QbitAI

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

今天,GitHub发布了全新的软件包管理服务,叫GitHub Package Registry完全免费

有了它,用户可以把自己的软件包传上GitHub,就像发布源码那样。

官方介绍说,这项服务和NPMMaven等许多现有的包管理器都兼容。并且,今后还会支持更多。

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

消息一出,网友纷纷感受到了一统天下的趋势。

有人表示开心

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

也有不少人担心

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

那么,这到底是一项怎样的服务?会给包管理工具的世界,带来怎样的震荡?

大一统的包管理服务

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

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

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

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

现在,来具体介绍一下。

都有什么功能

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

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

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

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

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

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

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

软件可以发布成私有,也可以公开:

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

统一的身份和权限

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

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

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

详细信息,知己知彼

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

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

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

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

你要试试么

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

注册一下就可以用:

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

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

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

要变天了

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

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

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

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

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

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

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

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

他还说,自己内心百感交集:

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

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

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

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

另外,NPM的用户也在担心它的命运:

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

毕竟,NPM现在内外交困:

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

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

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

有人回复了这条评论:

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

—  —

版权所有,未经授权不得以任何形式转载及使用,违者必究。