Python社区  »  Git

完全免费!GitHub发布全新的软件包管理服务(附测试版地址)

THU数据派 • 1 周前 • 21 次点击  


本文经AI新媒体量子位(公众号ID:qbitai)授权转载,转载请联系出处。

本文约2000字,建议阅读5分钟。

本文为你介绍了GitHub发布了全新的软件包管理服务。


今天,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怎么处理了。


— 完 —

编辑:王菁

校对:龚力


Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/32969
 
21 次点击  
分享到微博