Live data from Hacker News

GitHub Package Registry

github.com

61–70 of 389 posts

Re: GitHub Package Registry

#61

Looks like Docker, node/npm, ruby/gems, java/maven, and nuget... but no Python? Seems an odd choice for the one to leave out.

Maybe because PyPI has a closer relationship with Python than the other package managers have with their core tech?

Re: GitHub Package Registry

#62
post #45

I'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.

Whenever pip can't find a package due to case or hyphen issues, I look at the access log, find out what pip is trying to retrieve, and rename things or use symlinks to fix it. Also, I manage the directory using git. (One of these days I'll try using git-annex or similar, but for now, a few gigabytes is not even close to being a burden.)

Re: GitHub Package Registry

#65
This solves the problem of managing private artifact repos in corp-land. If your org pays for GitHub, now you don't have to manage them. The only thing they need now is their own CI, and maybe some improved project management, and GitHub's going to be one gigantic gravy train.

Re: GitHub Package Registry

#66
post #59

If/when they add a build service (like Bitbucket Pipelines), they have a golden opportunity to provide a strong guarantee that a package was built from a particular Git commit (i.e. the source code wasn't modified to add malicious code). That would make me feel a lot better about using pre-built packages.

GitHub Actions?

Re: GitHub Package Registry

#68
post #31

This 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…

Have you tried Bintray? [1]

It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.

[1] https://bintray.com/

Re: GitHub Package Registry

#69

Looks like Docker, node/npm, ruby/gems, java/maven, and nuget... but no Python? Seems an odd choice for the one to leave out.

GitHub, at least from what I've seen publicly in the past, uses all the ones they support except maybe Java/Maven; I've never seen anything about them internally using Python.

So, it's not really all that surprising of an initial set of choices for them to make.

Re: GitHub Package Registry

#70

Is there a way I could let some CI service like Travis CI to ONLY publish the packages to this GitHub Package Registry? ONLY means I don't want to expose the entire GitHub account to Travis CI but allow only publishing to the registry. So if the GitHub key/access-token leaks somehow the possible damage would be limited by registry publishing scope. So something like scoped access tokens.

Yes. They showed in the demo that there will be a new scope for read/publish packages. So you can create a personal access token for Travis with only that scope.
Post reply on HN