14 ms·

The GitHub registry public beta is live

268 points by talal7860 7y ago

andyfleming 7y ago
I think this beta sign-up has been up for a bit already. It still just adds you to a wait list as far as I can tell, unless I missed something.
- max23_ 7y ago
  I signed this up when they first announced it but I still don't get the invite to access it. I am not sure how they choose who will have early access to it.
penagwin 7y ago
Any word on pricing?
- bdcravens 7y ago
  > GitHub Package Registry is free for all repositories during the beta. And it will always be free for public and open source repositories. https://github.com/features/package-registry https://github.com/features/package-registry
  - penagwin 7y ago
    Perfect thanks!
- deleted 7y ago
  [deleted]
hprotagonist 7y ago
There's no immediate mention of this on the site, but -- why did they select the package formats that they did? I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?
- OJFord 7y ago
  Some function of popularity on the platform and ease of implementation, I'm sure. And, I suspect (from python's noteworthy absence), degree to which the language's users were already (mis)using GitHub releases (or sites) for this purpose.
  - hprotagonist 7y ago
    yes but i pip install git+https://github.com... very often!
- Guillaume86 7y ago
  > There's no immediate mention of this on the site, but -- why did they select the package formats that they did? Don't know but the formats do not seem to match the Azure DevOps package feeds formats (some overlap of course but some missing in one, some missing in the other) so it's not from shared code.
- ageofwant 7y ago
  Perhaps because pip already supports git repos: git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit
  - Avamander 7y ago
    And it also works from requirements.txt
- alexbecker 7y ago
  Running a python package registry has some unique challenges, so it makes sense not to start with it (I run such a registry: https://pydist.com https://pydist.com). For example, Python has a distinction between distributions (the actual file downloaded, e.g. a tarfile or a manylinux1 wheel) and versions that doesn't exist in most other languages.
  - takeda 7y ago
catern 7y ago
The lack of "the" makes this read a bit weirdly: >GitHub Package Registry allows you to develop your code and host your packages in one place. You can use packages from GitHub Package Registry as a dependency in your source code on GitHub. "Package registry" is a fairly generic term, so to me it would be natural to refer to this product as "the Github package registry" (capitalized or not). Is there a name for deliberately avoiding "the" in this way?
- superzamp 7y ago
  marketing?
- dang 7y ago
  I don't know, but have a 'the' above.
- skluck 7y ago
  I wonder if Microsoft influenced the naming, they often use generic terms for product names. * Microsoft Office * Microsoft SQL Server * MVC Framework
danShumway 7y ago
> is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects. I am... really confused by this. Isn't this just Github? Github is a hosting service that allows you to host your packages and code in one place. It has testing and publishing pipeline support, you can add artifacts/releases, make your packages private or public, host different types of software at the same time, and it's compatible with most existing dependency systems, including NodeJS. I can see this has more download statistics, which is nice. And it has a policy that artifacts can't be deleted, which is very nice. Is that it though? I know I have to be missing something; what can I do now that I couldn't already do with Github as is?
- chrisseaton 7y ago
  > what can I do now that I couldn't already do with Github as is? Before this new service how would you use GitHub as a source for installing, for example, Maven packages?
  - farmerbb 7y ago
    There's https://jitpack.io https://jitpack.io, but it's a third-party service. Having first-party support for Maven artifacts served by GitHub will be quite nice.
  - danShumway 7y ago
    I guess I'm not sure how Maven works then -- I thought it was just downloading package binaries? I would use Github releases for that and link to the binary directly. I'd use a CI to auto-build and publish a new release binary whenever I pushed to master. Does Maven do something more complicated like automatically figure out which platform binary to pull?
    - chrisseaton 7y ago
      It's the file layout, for just one thing. You can't just point Maven (or many package managers) at a simple HTTP server without the correct layout. If you could... they wouldn't have built this.
thefounder 7y ago
I like Go more. The git/hg/svn/bz repository is the "package". No custom (and central) "registry"
- sooheon 7y ago
  This is not unique to Go, every language I work with can use dependencies in this way.
  - thanatos_dem 7y ago
    How about java projects? How can I add a dependency to a project I’m building without it being published to a maven repo, for instance?
    - dragonwriter 7y ago
      > How about java projects? How can I add a dependency to a project I’m building without it being published to a maven repo, for instance? You can use Gradle, which supports source repositories, instead of Maven: https://blog.gradle.org/introducing-source-dependencies https://blog.gradle.org/introducing-source-dependencies
  - thefounder 7y ago
    I guess you don't work with many languages
- penagwin 7y ago
  Same with npm at least with git.
- jayflux 7y ago
  There was a Go dependency that got deleted (repo removed) and screwed everyone else’s project up, so I’m not sure this is perfect either.
  - tacticus 7y ago
hobofan 7y ago
At least in the case of NPM (I don't know as much about the other ones): Doesn't that create a huge opportunity for hijacking attacks, where someone publishes a malicious NPM package in the default NPM registry under the scope identical to a Github organization/username?
- IggleSniggle 7y ago
  Maaaaaaybe. But I don’t think so in practice. At least not yet. Would probably be good to see package.json evolve to allow specification of registry. In my personal experience of using a private npm registry, you pay a lot more attention to package-lock. package.json could probably evolve to specify registry in a similar way.
  - judge2020 7y ago
    Considering the npm corporation had layoffs[0], and how they haven't merged any PRs from outside sources in a while (this may have changed, but here's an example[1]), They might not be stoked to reduce the friction of linking to other package repositories from withing package.json. 0: https://hub.packtpub.com/surprise-npm-layoffs-raise-questions-about-the-company-culture/ https://hub.packtpub.com/surprise-npm-layoffs-raise-question... 1: https://github.com/npm/cli/pull/125#issuecomment-474127391 https://github.com/npm/cli/pull/125#issuecomment-474127391
- quickthrower2 7y ago
  That is an interesting idea, playing on people's confusion as to where to install from. And someone is going to put the super terse `npm i -g mytool` on their README.md page (because it's all about the easy installs isn't it!) and forget to say "change your registry to github" and boom!
  - hobofan 7y ago
    Not even "someone". Exactly that command is available to copy to clipboard on the page of this new feature. Yeah, a small link to the instructions is printed underneath it, but most users - especially the ones that are new to package managers and the most vulnerable - will ignore that.
codingslave 7y ago
Github is going to be the source of code and data that neural networks use to write software. There is so much data on there, and it will only increase. There's only so many coding patterns. Get ready to be a fill in the blanks developer
nickjj 7y ago
Any word on what the price will be for private repos after the beta ends? Would be interesting to see how it compares to Docker Hub for hosting private images.
- andyfleming 7y ago
  I think if it's at all comparable, GitHub will win out. It just seems convenient to not have one more subscription with another provider. Plus, hopefully, it will all be integrated well workflow-wise with a repository with actions that publish to the registry.
  - devmunchies 7y ago
    if docker loses, then who will maintain docker?
    - andyfleming 7y ago
      There's more to docker than Docker Hub, but I'm not sure what % of their revenue is from Docker Hub. Even if GitHub "wins" there will still be a lot on Docker Hub. Also, it's already possible to use other registries like Amazon's ECR or Google Cloud's GCR, or even your own private one.
craigds 7y ago
Still no python support :(
- ageofwant 7y ago
  A bit disappointing yes, but pip has had support for git repo's for many years. In requirements.txt: git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit So perhaps that's why, still would like to have a github hosted devpi
  - craigds 7y ago
    git urls are tricky to use with many tools (like pip-compile) though. At best they're slow, since things like "what's the latest version?" require downloading the repo. We forked some things into a private DevPI instance at present for that reason (well, also for latency)
    - orf 7y ago
      Pipenv locks the VCS dependency to the commit, making pulling very fast.
      - andyfleming 7y ago
        Does it do a shallow pull or pull a tarball of the source?
        orf 7y ago
        Shallow pull. You can specify the github tarball URL if you’d prefer.
mvanbaak 7y ago
Deleting packages is not supported. Sobhow to handle a compromised package? Looks like you have to contact github and hope the act fast. Oh, and no pip registry :(
- aaomidi 7y ago
  Probably because deleting causes a lot of issues. They should have a release and snapshot branches.
- gkoberger 7y ago
  The alternate is that critical infrastructure can just... disappear. Like "leftpad", but worse. GitHub is already really great about alerting you with critical issues. Whenever there's a security bug, it pops up in our repo (and with Dependabot, it's become automatic).
  - jmb12686 7y ago
    I have appreciated the automated notifications from GitHib for projects that have known vulnerable dependencies in my package.json(s). I just looked up Dependabot and linked it with a repo that I already have robust testing and CI pipeline for. Preliminarily Dependabot is great! It automatically updates by dependencies to the latest versions and submits individual PRs. Since I have TravisCI hooked up to this particular repo, I can see all the test results for each PR and can (confidently) merge the changes into master without manually firing up my personal dev machine(s) and manually performing what Dependabot just did. Anyway, thanks for the tip!
- smudgymcscmudge 7y ago
  Deleting was supported at initial release. Removing delete support was one of the first changes they made. My guess is that was because of the feedback they got here and on twitter.
andyfleming 7y ago
I hope they add robots accounts like Quay.io (https://docs.quay.io/glossary/robot-accounts.html https://docs.quay.io/glossary/robot-accounts.html).
- justincormack 7y ago
  It says that permissions are the same as the github repo, so you can create github accounts and grant access, or use tokens.
  - andyfleming 7y ago
    It's nice to be able to manage machine/robot accounts more directly though. On top of that, for orgs, you'd be paying monthly for each user you add.
jonny383 7y ago
Honestly, GitHub has been going down hill for about 18 months now. It all started with the ":D Set status" feature. I give it another two years before Microsoft has officially turned GitHub into a 2021 version of Skype
- cranky_coder 7y ago
  I’m confused, is this an example of one of those “:D Set status features”? It seems useful to me...
  - jonny383 7y ago
    This is a glorified wrapper written around existing package managers. I wouldn't call that useful.
    - dstaley 7y ago
      No, this is a reimplementation of basically every major package server. Now, instead of hosting your Ruby gems on rubygems, NPM packages on the NPM registry, and Python packages on PyPI, you can host them directly alongside your source code. The tools by which you access these package registries are the same, but they can now be backed directly by GitHub.
      - jonny383 7y ago
        Which is a glorified wrapper. Why on earth would you make a decision to lock up all of your eggs in the Microsoft basket? Diversity is a good thing. Just look at what's happened to the web industry with Chrome, and now it's basically too late.
        gotts 7y ago
        I couldn't agree more with jonny383. Why so many people consider centralizing everything as always and universally a good thing? Some people just don't seem to want to learn from history. Some short-term conveniences come at a very high price in the long run.
carapace 7y ago
FWIW, Software Heritage already has your github repos: https://www.softwareheritage.org/ https://www.softwareheritage.org/ https://hn.algolia.com/?query=Software%20Heritage&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=Software%20Heritage&sort=byPop... And GNU Guix at least will transparently fallback to them: > Since Software Heritage archives source code for the long term, Guix can fall back to the Software Heritage archive whenever it fails to download source code from its original location. The way this fallback has been designed, package definitions don’t need to be modified: they still refer to the original source code URL, but the downloading machinery transparently comes to Software Heritage when needed. https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/ https://www.softwareheritage.org/2019/04/18/software-heritag...
- jolmg 7y ago
  You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Firefox or Chrome from a decade ago as easily as I can install the latest versions. I wonder if it'd be too crazy to add git-awareness to the Nix utils. Like tell nix to install version X of some package, so in the nixpkgs repo it would check the history of the corresponding file to find the commit where it last was that version, checkout that commit, build the package and its dependencies, and then return to the branch it was at.
  - eridius 7y ago
    That would be cool, though I'd prefer an approach where the channels maintain a database of the pname/version combo for every package in the channel, and an API where you can query to find out what version of the channel contained a given pname/version combo for a given attribute path. Then you can just download the tarball for that version, no git needed anywhere. In theory, that database could also just be included in the channel so it could be queried locally, but I don't know how large it would end up being.
tasogare 7y ago
> limited public beta "Limited" should have been in the title, because it makes it a not so public beta.
no_wizard 7y ago
For all the features GitHub has, this is the only one that myself and those that I know personally have made us care and watch very closely what GitHub does with this. We've been looking for a simple way to streamline releases. Right now everything we have at my job is on GitLab and I use GitLab personally (though I have a github account, of course). I prefer GitLab in every way, but this feature alone might be a good enough reason to switch. It would make releases just so darn easy. The only thing I hope (which is not made clear) is that the stipulation that you can't easily delete a package on the registry (According to the link, its only for GDPR requests and legal reasons) is something that, for instance, an Enterprise account wouldn't have. I already have our purchasing team looking into it, thats how serious this is. If the API for hitting these packages is any good, its gonna be so hard to resist. I really hope GitLab has a good response to this. To wit, since GitLab is custom hosted, I wonder how hard it would be to add this into the CE edition.... With all that said, I wonder what the hidden limits will be. Imagine if instead of NPM maintaing all of its servers, it was just a thin database that had better routing to github releases? Would that fall afoul with GitHub? I mean, whats the point of maintaining your own distribution server when GitHub can front all the hosting costs and all you have to do is map the name of a package to its Github Package Release URL. I could see NPM, PyPI et. al. just doing that, instead of having their own servers. Maybe its a good idea to run additional cache nodes, but GitHub being the main place where release code lives for you package index would cut the bills significantly no?
- itslennysfault 7y ago
  This is a feature Azure DevOps (formerly Visual Studio Team Services) has had for at least 3 years now. Their repositories Maven, Gradle, Pip, and NuGet in addition to NPM. I'm always surprised more people don't use it. It's a full featured ticket system, git (PRs / etc), package feeds, and ci/cd in one neat package.
  - no_wizard 7y ago
    I did not know that. Though, we aren't on Azure for anything at all (AWS for some HIPAA stuff, Google Cloud or our own proxmox cluser for the rest). I know Azure Pipelines is becoming the sort of defacto automated CD/CI pipeline though (used to be Travis for so long) and I've heard nothing but good things about that. Might have to take a look.
samcat116 7y ago
Weird that the announced support for SPM packages but I don't see that on this page anywhere.
- twodayslate 7y ago
  Perhaps after the Xcode 11 beta?
psadauskas 7y ago
Deja vu https://github.blog/2008-04-25-github-s-rubygem-server/ https://github.blog/2008-04-25-github-s-rubygem-server/ And then removed 16 months later: https://github.blog/2009-10-08-gem-building-is-defunct/ https://github.blog/2009-10-08-gem-building-is-defunct/ Hopefully this one lasts longer.
- rogerkirkness 7y ago
  Customers ability to 1. Punish innovation and 2. Punish a lack of innovation is a little bit hard to overestimate as a Product Manager. Experimentation = bad, no experimentation = also bad. It's like how Google makes some of the best software ever, and also people savagely denounce them every time they kill a failing product. As if they would have learned as fast if they either didn't make the product to begin with or kept it around to languish and maintain.
  - tidepod12 7y ago
    It isn't a customer's responsibility to be a company's guinea pig, and it's not a secret that customers would be unhappy that tech companies treat them as such. This is especially true when Product Managers intentionally implement features that take advantage of users by monetizing their data and then implementing high switching costs that make it even more painful for the customer once the Product Manager ends their "experiment". If tech companies want to perform market research by experimenting on customers, they should do the same thing that other industries do and compensate the experiment subjects, not take advantage of them. If you want to disrespect customers by treating them like disposable guinea pigs (and not even giving them the courtesy of notifying them they're part of an experiment), don't be surprised if they start to catch on and treat your company as if it's disposable, too.
    - rogerkirkness 7y ago
      The world would have almost no innovative technology if not for a period where customers tolerated "not good enough".
- 7y ago
hiccuphippo 7y ago
Any word on trying to tackle package build verification/reproductibility so users can be guaranteed that the package was built from the source code? The problems like with rubygems from yesterday and npm a few weeks back would be gone with something like that.
jrochkind1 7y ago
Looking at the ruby docs, my interpretation is that if a gem is published only on github registry, there's no good way to use it as an indirect dependency (no good way for a gem to list it as a dependency) -- any app using such a thing would have to know the list of all of these indirect dependencies on github registry, and list them individually in the top-level Gemfile, along with their correct github source. This seems to limit the utility for ruby. I'm not sure if other supported platforms have similar issues? You could already do a lot of what github registry for ruby does by using an existing feature where you could already point to a git repo (not just GH) in your `Gemfile`. What this adds is just the ability to resolve multiple versions from github using ordinary rubygems resolution. The existing feature forced you to manually specify a tag (hoping there was a predictable tag for a version) or SHA, or use whatever is on master HEAD.
- tehbeard 7y ago
  Other platforms (maven/java comes to mind) benefit somewhat due to the compiled nature of artifacts. The immutability of the packages is also handy as you pointed out by the hope and a prayer that a tag stays static. Is there not a global config for rubygems that would specify a list of registries to search for a package instead of having to add them to each project?
  - jrochkind1 7y ago
    The way they have set things up, every github account/organization (the first thing after a slash) is it's own separate 'source' to rubygems. (I am sure they have done this because it would be inconvenient to integrate with rubygems/bundler any other way). So you'd still need to add a separate source for each dependency hosted on github to your own project Gemfile. Including for each indirect dependency, knowing which indirect dependencies exist that need a github repo source. If you could list this for the entire project... it'd probably be a performance issue as rubygems/bundler check every repo source you list for every dependency (including every indirect dependency; a Rails app has hundreds, still an order of magnitude or two less than a react JS project heh). Even if you could only list "github's ruby registry" once (per project? for your account? and keep in mind this is hypothetical, you can't), it would still mean any gem expressing a dependency on another gem hosted on github would have to include in it's instructions "oh, if you use this, you need to manually make sure to add github to your sources. Or you'll get an error that says some gem you've never heard of can't be found, and have no idea how to fix it." Unless it's a bid to get _everyone_ to do that, and basically make github ruby registry a standard part of the ecosystem that everyone just always adds to every project. I don't think there's enough/any value added by the github ruby registry to get the ecosystem to shift like that. It's unclear what it does that the 'standard' rubygems.org gem source doesn't do already (unless rubygems.org can't solve their recent severe compromised account security problems... but as it is, with the indirect dependency problem, I think github registry will be too painful to use even if you'd like to to escape rubygems.org security issues). https://help.github.com/en/articles/configuring-rubygems-for-use-with-github-package-registry https://help.github.com/en/articles/configuring-rubygems-for...
wbillingsley 7y ago
I came across this one the other day, which looks like it does this plus producing the binary package for you: https://jitpack.io/ https://jitpack.io/ (No, I'm not related to that company in any way. I just saw it yesterday and thought it seemed like a neater solution.)
baybal2 7y ago
No RPM or DEB supported
gotts 7y ago
I believe it's going to affect the whole developer community in a bad way. Right now, all the major package manager are indirectly making each other better, they experiment, improve and borrow good ideas from each other. It's open-source and there is a little barrier for developers to contribute. If n years from now GitHub becomes the defacto standard for package managers and replaces all the existing ones the further innovation will be much slower. It might transform into "Want to improve package managers? You have to work for Microsoft"
- txcwpalpha 7y ago
  I think you're conflating package managers and package registries here. This GitHub product has almost no overlap with package managers like pip, gem, maven, or npm. It is not a replacement for docker. This is a replacement for npmjs.com (the hosting service, which is not the same thing as npm the package manager), or for rubygems.org (again, the hosting service, not the gem tool), or for Docker Hub. If anything, this may actually improve the collaboration between package manager developers because there will now be a large development team that will be working with the backend of various package registries and will have better insight into what each one is doing wrong and what each one is doing right.
needusername 7y ago
They do not have a published list of requirements for Maven artifacts. This does not give a good first impression.

268 points by talal7860 7y ago

I think this beta sign-up has been up for a bit already. It still just adds you to a wait list as far as I can tell, unless I missed something.

max23_ 7y ago
I signed this up when they first announced it but I still don't get the invite to access it. I am not sure how they choose who will have early access to it.

penagwin 7y ago

Any word on pricing?

bdcravens 7y ago
> GitHub Package Registry is free for all repositories during the beta. And it will always be free for public and open source repositories. https://github.com/features/package-registry https://github.com/features/package-registry
- penagwin 7y ago
  Perfect thanks!
deleted 7y ago
[deleted]

hprotagonist 7y ago

There's no immediate mention of this on the site, but -- why did they select the package formats that they did? I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?

OJFord 7y ago
Some function of popularity on the platform and ease of implementation, I'm sure. And, I suspect (from python's noteworthy absence), degree to which the language's users were already (mis)using GitHub releases (or sites) for this purpose.
- hprotagonist 7y ago
  yes but i pip install git+https://github.com... very often!
Guillaume86 7y ago
> There's no immediate mention of this on the site, but -- why did they select the package formats that they did? Don't know but the formats do not seem to match the Azure DevOps package feeds formats (some overlap of course but some missing in one, some missing in the other) so it's not from shared code.
ageofwant 7y ago
Perhaps because pip already supports git repos: git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit
- Avamander 7y ago
  And it also works from requirements.txt
alexbecker 7y ago
Running a python package registry has some unique challenges, so it makes sense not to start with it (I run such a registry: https://pydist.com https://pydist.com). For example, Python has a distinction between distributions (the actual file downloaded, e.g. a tarfile or a manylinux1 wheel) and versions that doesn't exist in most other languages.
- takeda 7y ago

catern 7y ago

The lack of "the" makes this read a bit weirdly: >GitHub Package Registry allows you to develop your code and host your packages in one place. You can use packages from GitHub Package Registry as a dependency in your source code on GitHub. "Package registry" is a fairly generic term, so to me it would be natural to refer to this product as "the Github package registry" (capitalized or not). Is there a name for deliberately avoiding "the" in this way?

superzamp 7y ago
marketing?
dang 7y ago
I don't know, but have a 'the' above.
skluck 7y ago
I wonder if Microsoft influenced the naming, they often use generic terms for product names. * Microsoft Office * Microsoft SQL Server * MVC Framework

danShumway 7y ago

> is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects. I am... really confused by this. Isn't this just Github? Github is a hosting service that allows you to host your packages and code in one place. It has testing and publishing pipeline support, you can add artifacts/releases, make your packages private or public, host different types of software at the same time, and it's compatible with most existing dependency systems, including NodeJS. I can see this has more download statistics, which is nice. And it has a policy that artifacts can't be deleted, which is very nice. Is that it though? I know I have to be missing something; what can I do now that I couldn't already do with Github as is?

chrisseaton 7y ago
> what can I do now that I couldn't already do with Github as is? Before this new service how would you use GitHub as a source for installing, for example, Maven packages?
- farmerbb 7y ago
  There's https://jitpack.io https://jitpack.io, but it's a third-party service. Having first-party support for Maven artifacts served by GitHub will be quite nice.
- danShumway 7y ago
  I guess I'm not sure how Maven works then -- I thought it was just downloading package binaries? I would use Github releases for that and link to the binary directly. I'd use a CI to auto-build and publish a new release binary whenever I pushed to master. Does Maven do something more complicated like automatically figure out which platform binary to pull?
  - chrisseaton 7y ago
    It's the file layout, for just one thing. You can't just point Maven (or many package managers) at a simple HTTP server without the correct layout. If you could... they wouldn't have built this.

thefounder 7y ago

I like Go more. The git/hg/svn/bz repository is the "package". No custom (and central) "registry"

sooheon 7y ago
This is not unique to Go, every language I work with can use dependencies in this way.
- thanatos_dem 7y ago
  How about java projects? How can I add a dependency to a project I’m building without it being published to a maven repo, for instance?
  - dragonwriter 7y ago
    > How about java projects? How can I add a dependency to a project I’m building without it being published to a maven repo, for instance? You can use Gradle, which supports source repositories, instead of Maven: https://blog.gradle.org/introducing-source-dependencies https://blog.gradle.org/introducing-source-dependencies
- thefounder 7y ago
  I guess you don't work with many languages
penagwin 7y ago
Same with npm at least with git.
jayflux 7y ago
There was a Go dependency that got deleted (repo removed) and screwed everyone else’s project up, so I’m not sure this is perfect either.
- tacticus 7y ago

hobofan 7y ago

At least in the case of NPM (I don't know as much about the other ones): Doesn't that create a huge opportunity for hijacking attacks, where someone publishes a malicious NPM package in the default NPM registry under the scope identical to a Github organization/username?

IggleSniggle 7y ago
Maaaaaaybe. But I don’t think so in practice. At least not yet. Would probably be good to see package.json evolve to allow specification of registry. In my personal experience of using a private npm registry, you pay a lot more attention to package-lock. package.json could probably evolve to specify registry in a similar way.
- judge2020 7y ago
  Considering the npm corporation had layoffs[0], and how they haven't merged any PRs from outside sources in a while (this may have changed, but here's an example[1]), They might not be stoked to reduce the friction of linking to other package repositories from withing package.json. 0: https://hub.packtpub.com/surprise-npm-layoffs-raise-questions-about-the-company-culture/ https://hub.packtpub.com/surprise-npm-layoffs-raise-question... 1: https://github.com/npm/cli/pull/125#issuecomment-474127391 https://github.com/npm/cli/pull/125#issuecomment-474127391
quickthrower2 7y ago
That is an interesting idea, playing on people's confusion as to where to install from. And someone is going to put the super terse `npm i -g mytool` on their README.md page (because it's all about the easy installs isn't it!) and forget to say "change your registry to github" and boom!
- hobofan 7y ago
  Not even "someone". Exactly that command is available to copy to clipboard on the page of this new feature. Yeah, a small link to the instructions is printed underneath it, but most users - especially the ones that are new to package managers and the most vulnerable - will ignore that.

codingslave 7y ago

Github is going to be the source of code and data that neural networks use to write software. There is so much data on there, and it will only increase. There's only so many coding patterns. Get ready to be a fill in the blanks developer

nickjj 7y ago

Any word on what the price will be for private repos after the beta ends? Would be interesting to see how it compares to Docker Hub for hosting private images.

andyfleming 7y ago
I think if it's at all comparable, GitHub will win out. It just seems convenient to not have one more subscription with another provider. Plus, hopefully, it will all be integrated well workflow-wise with a repository with actions that publish to the registry.
- devmunchies 7y ago
  if docker loses, then who will maintain docker?
  - andyfleming 7y ago
    There's more to docker than Docker Hub, but I'm not sure what % of their revenue is from Docker Hub. Even if GitHub "wins" there will still be a lot on Docker Hub. Also, it's already possible to use other registries like Amazon's ECR or Google Cloud's GCR, or even your own private one.

craigds 7y ago

Still no python support :(

ageofwant 7y ago
A bit disappointing yes, but pip has had support for git repo's for many years. In requirements.txt: git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit So perhaps that's why, still would like to have a github hosted devpi
- craigds 7y ago
  git urls are tricky to use with many tools (like pip-compile) though. At best they're slow, since things like "what's the latest version?" require downloading the repo. We forked some things into a private DevPI instance at present for that reason (well, also for latency)
  - orf 7y ago
    Pipenv locks the VCS dependency to the commit, making pulling very fast.
    - andyfleming 7y ago
      Does it do a shallow pull or pull a tarball of the source?
      - orf 7y ago
        Shallow pull. You can specify the github tarball URL if you’d prefer.

mvanbaak 7y ago

Deleting packages is not supported. Sobhow to handle a compromised package? Looks like you have to contact github and hope the act fast. Oh, and no pip registry :(

aaomidi 7y ago
Probably because deleting causes a lot of issues. They should have a release and snapshot branches.
gkoberger 7y ago
The alternate is that critical infrastructure can just... disappear. Like "leftpad", but worse. GitHub is already really great about alerting you with critical issues. Whenever there's a security bug, it pops up in our repo (and with Dependabot, it's become automatic).
- jmb12686 7y ago
  I have appreciated the automated notifications from GitHib for projects that have known vulnerable dependencies in my package.json(s). I just looked up Dependabot and linked it with a repo that I already have robust testing and CI pipeline for. Preliminarily Dependabot is great! It automatically updates by dependencies to the latest versions and submits individual PRs. Since I have TravisCI hooked up to this particular repo, I can see all the test results for each PR and can (confidently) merge the changes into master without manually firing up my personal dev machine(s) and manually performing what Dependabot just did. Anyway, thanks for the tip!
smudgymcscmudge 7y ago
Deleting was supported at initial release. Removing delete support was one of the first changes they made. My guess is that was because of the feedback they got here and on twitter.

andyfleming 7y ago

I hope they add robots accounts like Quay.io (https://docs.quay.io/glossary/robot-accounts.html https://docs.quay.io/glossary/robot-accounts.html).

justincormack 7y ago
It says that permissions are the same as the github repo, so you can create github accounts and grant access, or use tokens.
- andyfleming 7y ago
  It's nice to be able to manage machine/robot accounts more directly though. On top of that, for orgs, you'd be paying monthly for each user you add.

jonny383 7y ago

Honestly, GitHub has been going down hill for about 18 months now. It all started with the ":D Set status" feature. I give it another two years before Microsoft has officially turned GitHub into a 2021 version of Skype

cranky_coder 7y ago
I’m confused, is this an example of one of those “:D Set status features”? It seems useful to me...
- jonny383 7y ago
  This is a glorified wrapper written around existing package managers. I wouldn't call that useful.
  - dstaley 7y ago
    No, this is a reimplementation of basically every major package server. Now, instead of hosting your Ruby gems on rubygems, NPM packages on the NPM registry, and Python packages on PyPI, you can host them directly alongside your source code. The tools by which you access these package registries are the same, but they can now be backed directly by GitHub.
    - jonny383 7y ago
      Which is a glorified wrapper. Why on earth would you make a decision to lock up all of your eggs in the Microsoft basket? Diversity is a good thing. Just look at what's happened to the web industry with Chrome, and now it's basically too late.
      - gotts 7y ago
        I couldn't agree more with jonny383. Why so many people consider centralizing everything as always and universally a good thing? Some people just don't seem to want to learn from history. Some short-term conveniences come at a very high price in the long run.

carapace 7y ago

FWIW, Software Heritage already has your github repos: https://www.softwareheritage.org/ https://www.softwareheritage.org/ https://hn.algolia.com/?query=Software%20Heritage&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=Software%20Heritage&sort=byPop... And GNU Guix at least will transparently fallback to them: > Since Software Heritage archives source code for the long term, Guix can fall back to the Software Heritage archive whenever it fails to download source code from its original location. The way this fallback has been designed, package definitions don’t need to be modified: they still refer to the original source code URL, but the downloading machinery transparently comes to Software Heritage when needed. https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/ https://www.softwareheritage.org/2019/04/18/software-heritag...

jolmg 7y ago
You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Firefox or Chrome from a decade ago as easily as I can install the latest versions. I wonder if it'd be too crazy to add git-awareness to the Nix utils. Like tell nix to install version X of some package, so in the nixpkgs repo it would check the history of the corresponding file to find the commit where it last was that version, checkout that commit, build the package and its dependencies, and then return to the branch it was at.
- eridius 7y ago
  That would be cool, though I'd prefer an approach where the channels maintain a database of the pname/version combo for every package in the channel, and an API where you can query to find out what version of the channel contained a given pname/version combo for a given attribute path. Then you can just download the tarball for that version, no git needed anywhere. In theory, that database could also just be included in the channel so it could be queried locally, but I don't know how large it would end up being.

tasogare 7y ago

> limited public beta "Limited" should have been in the title, because it makes it a not so public beta.

no_wizard 7y ago

For all the features GitHub has, this is the only one that myself and those that I know personally have made us care and watch very closely what GitHub does with this. We've been looking for a simple way to streamline releases. Right now everything we have at my job is on GitLab and I use GitLab personally (though I have a github account, of course). I prefer GitLab in every way, but this feature alone might be a good enough reason to switch. It would make releases just so darn easy. The only thing I hope (which is not made clear) is that the stipulation that you can't easily delete a package on the registry (According to the link, its only for GDPR requests and legal reasons) is something that, for instance, an Enterprise account wouldn't have. I already have our purchasing team looking into it, thats how serious this is. If the API for hitting these packages is any good, its gonna be so hard to resist. I really hope GitLab has a good response to this. To wit, since GitLab is custom hosted, I wonder how hard it would be to add this into the CE edition.... With all that said, I wonder what the hidden limits will be. Imagine if instead of NPM maintaing all of its servers, it was just a thin database that had better routing to github releases? Would that fall afoul with GitHub? I mean, whats the point of maintaining your own distribution server when GitHub can front all the hosting costs and all you have to do is map the name of a package to its Github Package Release URL. I could see NPM, PyPI et. al. just doing that, instead of having their own servers. Maybe its a good idea to run additional cache nodes, but GitHub being the main place where release code lives for you package index would cut the bills significantly no?

itslennysfault 7y ago
This is a feature Azure DevOps (formerly Visual Studio Team Services) has had for at least 3 years now. Their repositories Maven, Gradle, Pip, and NuGet in addition to NPM. I'm always surprised more people don't use it. It's a full featured ticket system, git (PRs / etc), package feeds, and ci/cd in one neat package.
- no_wizard 7y ago
  I did not know that. Though, we aren't on Azure for anything at all (AWS for some HIPAA stuff, Google Cloud or our own proxmox cluser for the rest). I know Azure Pipelines is becoming the sort of defacto automated CD/CI pipeline though (used to be Travis for so long) and I've heard nothing but good things about that. Might have to take a look.

samcat116 7y ago

Weird that the announced support for SPM packages but I don't see that on this page anywhere.

twodayslate 7y ago
Perhaps after the Xcode 11 beta?

psadauskas 7y ago

Deja vu https://github.blog/2008-04-25-github-s-rubygem-server/ https://github.blog/2008-04-25-github-s-rubygem-server/ And then removed 16 months later: https://github.blog/2009-10-08-gem-building-is-defunct/ https://github.blog/2009-10-08-gem-building-is-defunct/ Hopefully this one lasts longer.

rogerkirkness 7y ago
Customers ability to 1. Punish innovation and 2. Punish a lack of innovation is a little bit hard to overestimate as a Product Manager. Experimentation = bad, no experimentation = also bad. It's like how Google makes some of the best software ever, and also people savagely denounce them every time they kill a failing product. As if they would have learned as fast if they either didn't make the product to begin with or kept it around to languish and maintain.
- tidepod12 7y ago
  It isn't a customer's responsibility to be a company's guinea pig, and it's not a secret that customers would be unhappy that tech companies treat them as such. This is especially true when Product Managers intentionally implement features that take advantage of users by monetizing their data and then implementing high switching costs that make it even more painful for the customer once the Product Manager ends their "experiment". If tech companies want to perform market research by experimenting on customers, they should do the same thing that other industries do and compensate the experiment subjects, not take advantage of them. If you want to disrespect customers by treating them like disposable guinea pigs (and not even giving them the courtesy of notifying them they're part of an experiment), don't be surprised if they start to catch on and treat your company as if it's disposable, too.
  - rogerkirkness 7y ago
    The world would have almost no innovative technology if not for a period where customers tolerated "not good enough".
7y ago

hiccuphippo 7y ago

Any word on trying to tackle package build verification/reproductibility so users can be guaranteed that the package was built from the source code? The problems like with rubygems from yesterday and npm a few weeks back would be gone with something like that.

jrochkind1 7y ago

Looking at the ruby docs, my interpretation is that if a gem is published only on github registry, there's no good way to use it as an indirect dependency (no good way for a gem to list it as a dependency) -- any app using such a thing would have to know the list of all of these indirect dependencies on github registry, and list them individually in the top-level Gemfile, along with their correct github source. This seems to limit the utility for ruby. I'm not sure if other supported platforms have similar issues? You could already do a lot of what github registry for ruby does by using an existing feature where you could already point to a git repo (not just GH) in your `Gemfile`. What this adds is just the ability to resolve multiple versions from github using ordinary rubygems resolution. The existing feature forced you to manually specify a tag (hoping there was a predictable tag for a version) or SHA, or use whatever is on master HEAD.

tehbeard 7y ago
Other platforms (maven/java comes to mind) benefit somewhat due to the compiled nature of artifacts. The immutability of the packages is also handy as you pointed out by the hope and a prayer that a tag stays static. Is there not a global config for rubygems that would specify a list of registries to search for a package instead of having to add them to each project?
- jrochkind1 7y ago
  The way they have set things up, every github account/organization (the first thing after a slash) is it's own separate 'source' to rubygems. (I am sure they have done this because it would be inconvenient to integrate with rubygems/bundler any other way). So you'd still need to add a separate source for each dependency hosted on github to your own project Gemfile. Including for each indirect dependency, knowing which indirect dependencies exist that need a github repo source. If you could list this for the entire project... it'd probably be a performance issue as rubygems/bundler check every repo source you list for every dependency (including every indirect dependency; a Rails app has hundreds, still an order of magnitude or two less than a react JS project heh). Even if you could only list "github's ruby registry" once (per project? for your account? and keep in mind this is hypothetical, you can't), it would still mean any gem expressing a dependency on another gem hosted on github would have to include in it's instructions "oh, if you use this, you need to manually make sure to add github to your sources. Or you'll get an error that says some gem you've never heard of can't be found, and have no idea how to fix it." Unless it's a bid to get _everyone_ to do that, and basically make github ruby registry a standard part of the ecosystem that everyone just always adds to every project. I don't think there's enough/any value added by the github ruby registry to get the ecosystem to shift like that. It's unclear what it does that the 'standard' rubygems.org gem source doesn't do already (unless rubygems.org can't solve their recent severe compromised account security problems... but as it is, with the indirect dependency problem, I think github registry will be too painful to use even if you'd like to to escape rubygems.org security issues). https://help.github.com/en/articles/configuring-rubygems-for-use-with-github-package-registry https://help.github.com/en/articles/configuring-rubygems-for...

wbillingsley 7y ago

I came across this one the other day, which looks like it does this plus producing the binary package for you: https://jitpack.io/ https://jitpack.io/ (No, I'm not related to that company in any way. I just saw it yesterday and thought it seemed like a neater solution.)

baybal2 7y ago

No RPM or DEB supported

gotts 7y ago

I believe it's going to affect the whole developer community in a bad way. Right now, all the major package manager are indirectly making each other better, they experiment, improve and borrow good ideas from each other. It's open-source and there is a little barrier for developers to contribute. If n years from now GitHub becomes the defacto standard for package managers and replaces all the existing ones the further innovation will be much slower. It might transform into "Want to improve package managers? You have to work for Microsoft"

txcwpalpha 7y ago
I think you're conflating package managers and package registries here. This GitHub product has almost no overlap with package managers like pip, gem, maven, or npm. It is not a replacement for docker. This is a replacement for npmjs.com (the hosting service, which is not the same thing as npm the package manager), or for rubygems.org (again, the hosting service, not the gem tool), or for Docker Hub. If anything, this may actually improve the collaboration between package manager developers because there will now be a large development team that will be working with the backend of various package registries and will have better insight into what each one is doing wrong and what each one is doing right.

needusername 7y ago

They do not have a published list of requirements for Maven artifacts. This does not give a good first impression.