So... does this basically put Gemfury out of business?
Gemfury supports Python, so OK for now.
GitHub Package Registry
251–260 of 389 posts
Re: GitHub Package Registry
#252Do I want to use Github for this? I kind of like the npm model where they say "don't cache it, we guarantee as much capacity as you want to re-download packages". I use a lot of go modules, and each of our container builds ends up fetching them all. Github rate limits this and you have to either vendor the modules or provide a caching go module proxy (Athens, etc.). Meanwhile, npm just uses Cloudflare which seems hap…
Why does every docker image build have to pull the packages? Are you force rebuilding and defeating docker's cache mechanism?
Re: GitHub Package Registry
#253I'm worried about the resiliency of code distribution as we continue the trend of centralizing distribution in a few large companies. GitHub has had service outages in the past, so what happens when not just our repositories but also now packages are not accessible the next time that happens? It would be great if they'd implement it using an open/decentralized protocol such as IPFS, so that even if GitHub went down t…
The problem is that hosting and bandwidth aren’t free and abuse is a big problem. Managing a distributed petabyte-scale archive which gets updated so frequently is a significant engineering problem even for a single party — now consider how you’d handle redundancy and routing when you can’t rely on any of the parties involved, and you have enough different objects being accessed to turn away most participants unless…
I hear those concerns, but I think there are clear ways to use decentralization to provide real benefit without running afoul of the issues you describe. For example, you can simply cache the packages you/your team are interested in locally, or on a shared local server for your entire office to use - which gives you fast p2p transfers, offline resiliency, and avoids serving any evil BLOBs or running into giant perf issues by trying to mirror and serve the entire registry. That's the way npm-on-ipfs (https://github.com/ipfs-shipyard/npm-on-ipfs) works - more details in this WIP blog entry https://github.com/ipfs/blog/pull/215/files?short_path=90aba... ;)
Re: GitHub Package Registry
#254If a government gets ssl certs of github then it will possible to MITM and distribute infected deps on millions of projects.
Same as if they pwn debian, redhat, docker, npm, maven (also used by gradle) or Microsoft Windows update infrastructure then? Or am I missing something?
Yes, but instead of having two pwn 5 now they just have to pwn 1.
Re: GitHub Package Registry
#255This will be very neat just as GitHub user experience is so far. Centralization is a questionable, but it looks like that the community values much more the convenience than decentralization and privacy. In any case, it is excellent to have multiple choices beside other registries. I hope that other services like https://newreleases.io will catch up and support this registry as well. But, maybe this would even make them obsolete and everything a bit more centralized.
Re: GitHub Package Registry
#256I'm disappointed it doesn't support Python. There's not a lot of options available for private Python package hosting, it would have been good to have another one.
To host a private Python package repository, I create a simple directory tree where the first level is the package name and the second level is the package (a tarball, zip, or a wheel) and I serve that tree over HTTPS using vanilla Apache or nginx with directory listings enabled. Then I use "bin/pip -i https://packages.example.com ..." to point to that repository. It's very low tech and it turns out that's all I need…
Yeah, self-hosting a Python package index is so easy that (free) hosting solutions don’t really offer much, which is probably why you don’t see many of those. Paid services do exist (the most recent is PyDist), but you’re really paying more for hosting than the index.
p.s. I believe pip has recently fixed the hyphen problem you mentioned. Sorry for the inconvenience! Please do report any issues if they still exist.
Re: GitHub Package Registry
#257This is really outstanding. It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype. On the other hand, it took me three days to release a new version of one of my artifacts the ot…
Publishing to Maven Central comes with a bunch of requirements ( https://central.sonatype.org/pages/requirements.html ) may be seen as a burden to packagers, but is certainly a delight for end-users of those packages. All packages are GPG signed, come with companion source and javadoc artifacts, and are guaranteed a certain amount of other metadata in the POM. There are "easier" repositories (like Bintray jcenter) bu…
Just compare how well organized and neet are the packages in Maven Cetral to mess in JCenter. JCenter is full of inconsistent trash. I can imagine people pushing packages there for testing and then just forget about them.
Not everyone and not all of them, of course. But while I was looking around to figure out which repository to choose as my main, JCenter has put me off. I still can't understand how people can easily trade convenience for quality.
Re: GitHub Package Registry
#258Doesn't this bifurcate the namespace of literally every packaging system they are supporting, or are they requiring `@author/`-namespaced package names? In the livestream he pokes around a github repo, sees it's one author, and decides that what makes it trustworthy? No GPG signing? The new Actions support (about 50 minutes into the live stream) for auto-publishing from master is pretty sweet. From the very cursory d…
Even with @author, my github username is someone else on npmjs. So installing “@me/module” will either get my module or the other guys depending on sources it would seem.
Re: GitHub Package Registry
#259Centralisation is indeed to be concerned. I really had hopes for https://open-registry.dev.
Re: GitHub Package Registry
#260No pip registry?