38 ms·

GitHub Package Registry

• chriskinsman 7y ago
  Link doesn't go anywhere?
  • zimbatm 7y ago
    Looks like it's going to be released soon: https://news.ycombinator.com/item?id=19881693 https://news.ycombinator.com/item?id=19881693
• sambroner 7y ago
  How did this get to the front page with a dead link?
  • rexpop 7y ago
    That's how big a deal it is.
• orliesaurus 7y ago
  404 wizardry
• chriskinsman 7y ago
  Bet this is embargoed until the 1:30 PM PST launch. Should have gone up post launch...
• deleted 7y ago
  [deleted]
• heinrichhartman 7y ago
  What a move! :clap: :clap: :clap: Apparently Microsoft has a few spare disks in their Cloud :)
• rjeli 7y ago
  This is awesome! But please implement Python packaging :cry:
• freedomben 7y ago
  This is super cool, but I worry that we've basically let a proprietary closed-source service be the de-facto standard for open source software. That really hampers my enthusiasm here.
• laith 7y ago
  https://www.instagram.com/p/Bt1N9cxllWf/?igshid=15gvydpfzrhj4 https://www.instagram.com/p/Bt1N9cxllWf/?igshid=15gvydpfzrhj...
• whalesalad 7y ago
  This is big. For a while we have needed a simple, intuitive and centralized artifact storage system for the modern age. I’ve been wanting to build something for ages but never made the time. I also think that this will also have the side effect of exposing a lot of people to package/build/dist tools from other ecosystems, which might help disseminate best practices outside of their walled gardens. Github helped do this with code, helping to put the spotlight on less popular or more cutting-edge languages This is going to solve a lot of problems for a lot of people.
• fn 7y ago
  So... does this basically put Gemfury out of business?
  • rykov 7y ago
    Gemfury supports Python, so OK for now.
• samschooler 7y ago
  Link is undead as of now for me (just switched).
• fooey 7y ago
  It's up now https://help.github.com/en/articles/about-github-package-registry https://help.github.com/en/articles/about-github-package-reg... Supports NPM, Docker, Maven, Nuget, RubyGems
• sambroner 7y ago
  This is going to be hard to avoid using for teams with a private git repo, especially private mono repos. The ability to provide any one with access to the repo access to the packages created from it removes an often frustrating management step.
• ezekg 7y ago
  bye bye npmjs.com?
  • nubs 7y ago
    I think the National Association of Pastoral Musicians will be fine. I assume you meant npmjs.com. :)
    • m463 7y ago
      meanwhile the International Brotherhood of Magicians has faded into obscurity.
• selrond 7y ago
  This could solve the trust issues with npm - you never know, whether the package you're installing is really from the source provided on its npm page
  • mceachen 7y ago
    Unless they require code signing, how does this help trust issues?
    • socrates667 7y ago
      They can create a special kind of Authentic GitHub signing that guarantees that the source you see is responsible for the binary being downloaded.
    • kevingadd 7y ago
      Code signing is a different sort of trust issue, in this case if the package file is coming from the same github repo page as the source code, you know it (AFAIK) had to come from someone with write access to the repository. vs having an npm package named (for example) nodejs, are you sure the npm package is authored by and owned by the same person or people that own the nodejs git repository? How do you verify that? There are many problems this doesn't solve of course but it does seem like it helps with the one I describe above, the connection between the source and the package. Unsolved problems of course would include things like 'did someone get unauthorized access to the git repo and put an artifact there' and 'did someone with unauthorized access push code to the repo and then have an artifact built'. Those are tough and real problems but I don't know if that's any different between this and say, npm. Code signing Helps with that but you have the same unauthorized access problem if some bad actor gets their signing key instead of repo access.
      • mceachen 7y ago
        > How do you verify that? I think if they required a user or org-namespaced package name, you'd get that. For example, if https://exiftool-vendored.js.org https://exiftool-vendored.js.org was `@mceachen/exiftool-vendored`, or `@photostructure/exiftool-vendored`, it's explicit, in the package name, who you're trusting. > ... did someone get unauthorized access ... If they required publishing to be via 2FA-authenticated users, and (if I can dream), GPG-signed commits, I think you get most of the way there. Github is starting greenfield here, and it's frustrating they didn't (at least afaict) require these small steps. When I'm looking at a given package, I'd like: 1. Assurance that the package was published by the author 2. Assurance that the package contents were generated, in an externally repeatable way, from a release tag. It seems like they could have lifted 1. by requiring 2FA and GPG. It seems like their new Actions tab could have given us 2. It may, I can't tell from the demo. And when I update my dependencies, I also want to see the diffs from the version I'm updating from. Github already has nice comparison views for arbitrary commit shas, so this should be doable as well.
• gigatexal 7y ago
  This is pretty interesting. Github really is becoming the social network that MS never seemed to be able to create. We already use it as our portfolio of work for potential employers. We collaborate with fellow enthusiasts and maybe even make new friends. We host our websites from it. Abuse it to store binaries, too. And now, along side, source code we can use it as a CDN of sorts to serve packages, for free, sounds pretty great. All they need now is a place to get coding questions answered (a la stackoverflow) and along with Github jobs it could be really compelling.
  • sambroner 7y ago
    Good points. I definitely see some people (ab)using Issues as a way to ask fairly generic coding questions. It might be time they open up another avenue for questions generally.
    • ne01 7y ago
      We already do this by adding the tag "Question" to the issue. But you are right a dedicated system for questions is better.
  • ben_jones 7y ago
    Or you know, it could just focus on its core competencies and be good (great?) at what it does. They don't need to eat the world to provide a positive impact to it...
    • deleted 7y ago
      [deleted]
    • bluGill 7y ago
      MS's core competency has always been developers. IBM called Microsoft for BASIC back in the day because without MS BASIC their computer was DOA to a lot of potential customers.
      • rectang 7y ago
• passenger 7y ago
  So what happens when a package on npm depends on a package on Github registry or vice versa?
  • mfatica 7y ago
    The same way it works today when you utilize packages from multiple repositories. Github isn't the first non-npm repository in existence.
    • jonnyscholes 7y ago
      What if they clash (eh user/package exist both on npmjs.com and GitHub)? Does it go through each of the configured repositories in sequence looking for a match?
      • adamscybot 7y ago
        You configure the NPM client on what your primary registry is. I think this github repo will mirror everything on NPM (?).
        • runeb 7y ago
          That will cause crashes between username scopes on npmjs and GitHub
• mmcclellan 7y ago
  Watching the live stream now (https://live-stream.github.com/ https://live-stream.github.com/). Will likely use the Docker support near immediately. Hoping Singularity will be supportable as well.
• adjkant 7y ago
  This is early and really depends on details, but this is a super exciting move and direction for Github. I'm wary of Microsoft ownership as it becomes even more of the home for code than before, but if they keep it true to its roots it could be a real positive.
• hn_throwaway_99 7y ago
  This is going to be a huge hit for things like NPM Enterprise and Artifactory. Especially useful for small/medium teams that's want to start from the get-go with an easy way to share modules that will scale as they grow.
  • brazzledazzle 7y ago
    Maybe for their SaaS but we’ll see how it’s implemented in GitHub Enterprise for on-prem. If it’s anything like LFS you’ll just be expected to keep growing your volume instead of doing something sane like supporting s3 or hell, even separate volumes.
    • symlinkk 7y ago
      What's the point in running on-prem if you're just going to store large files in S3 anyway? It makes perfect sense the way they decided on.
      • icebraining 7y ago
        Supporting the S3 API could still make sense, at least you could decouple it and run Minio or something.
      • brazzledazzle 7y ago
        On-prem doesn’t exclusively mean “in your data center” anymore. It’s about security and control, not where it’s hosted. They offer GitHub Enterprise AMIs for a reason.
• kissgyorgy 7y ago
  GitHub is coming after GitLab :D They first started with Boards, then Github Actions and now with this.
  • prh8 7y ago
    What does Gitlab have that this is competing with? I know Gitlab's docker registry but not of a package registry.
    • foxylion 7y ago
      Yes, it has a package registry feature for NPM and Maven: Maven: https://docs.gitlab.com/ee/user/project/packages/maven_repository.html https://docs.gitlab.com/ee/user/project/packages/maven_repos... NPM: https://docs.gitlab.com/ee/user/project/packages/npm_registry.html https://docs.gitlab.com/ee/user/project/packages/npm_registr...
      • jbergstroem 7y ago
        The NPM support is basically not more than a proof of concept. It cannot be used for anything production-like. https://twitter.com/eatingfoodbrb/status/1101461965036244993 https://twitter.com/eatingfoodbrb/status/1101461965036244993
        • boleary-gl 7y ago
          GitLab Product Manager here Thanks for your feedback on NPM registry support in GitLab. We release minimal viable change (MVC) and then iterate on our product functionality. Here are some of the issues we have related to NPM support: https://gitlab.com/gitlab-org/gitlab-ee/issues/10024 https://gitlab.com/gitlab-org/gitlab-ee/issues/10024 https://gitlab.com/gitlab-org/gitlab-ee/issues/10050 https://gitlab.com/gitlab-org/gitlab-ee/issues/10050 https://gitlab.com/gitlab-org/gitlab-ee/issues/9164 https://gitlab.com/gitlab-org/gitlab-ee/issues/9164 https://gitlab.com/gitlab-org/gitlab-ee/issues/9104 https://gitlab.com/gitlab-org/gitlab-ee/issues/9104
• jrockway 7y ago
  Do 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 happy to serve as many requests as I desire. In general, I find that caching/vendoring dependencies is the most sane thing to do, but it's not what, say, the Javascript world appears to be doing. Do we want to move towards a service that already rate-limits package fetches when we already have a service that doesn't?
  • zrail 7y ago
    The blog post says something about serving via a cdn. Are they also rate limiting?
  • schneidmaster 7y ago
    > Github rate limits this I would be shocked if GitHub rate limited this new package registry. They're just serving tarballs and static content, and it's a new system so they can fully architect it with scale in mind (i.e. a CDN). They rate limit current repository-related content because they have to dynamically generate most of it in response to requests (I assume they have caching here as well, but not static-file-behind-CDN level caching).
    • jopsen 7y ago
      But what about repo renames... Are packages immutable?
  • rich-tea 7y ago
    Why does every docker image build have to pull the packages? Are you force rebuilding and defeating docker's cache mechanism?
    • windexh8er 7y ago
      This isn't too surprising. Microsoft's DevOps in Azure does the same thing (or did I haven't looked at it in a few months). There was literally no point in using it until, as you've pointed out, a user can leverage cache. If I have a multistage build with an SDK that weighs in around 1GB why would I ever want to use a tool that pulls that down every run? I think, as many have said, that this is going after GitLab more than anyone else, although I can see a lot of users migrating away from Docker Hub given 1) the latest snafu/breach and 2) why keep my container repo over here and my container build pipeline over there? Doesn't make any sense and Docker Hub doesn't come with the pedigree of CDN baked in. I'm sure the same arguments work for other technologies in this consideration, but... Docker seems to continually be behind the 8-ball on the shifting field. My guess is Microsoft buys them in the next 3 years at a discount anyway. It fits their pattern of getting in front of the modern ecosystem and since Docker has leverage with containerd right now it would be an unsurprising move.
• mikepurvis 7y ago
  Looks like Docker, node/npm, ruby/gems, java/maven, and nuget... but no Python? Seems an odd choice for the one to leave out.
  • switch007 7y ago
    Bit like security alerts which were initially just JS and Ruby. Indeed odd.
    • josegonzalez 7y ago
      I don't find it odd at all. It's likely just "languages we use" and "languages that would see enterprise value". Certainly Ruby/Javascript fall into the former, and Java/C# fall into the latter. Not saying Python doesn't have enterprise value, but we have to consider that this is an MVP, so it makes sense for them to limit to a subset of languages they feel comfortable about.
  • femto113 7y ago
    Maybe because PyPI has a closer relationship with Python than the other package managers have with their core tech?
    • nerdponx 7y ago
      I don't see how that's relevant. Hosting your own Python package index isn't easier than hosting any other, as far as I'm aware.
      • femto113 7y ago
        Less technical and more political. Python has a bureaucracy that can take let’s say “a while” to decide things. If GitHub approached them about this it wouldn’t surprise me if they’re still debating whether to condone it.
        • femto113 7y ago
• luhn 7y ago
  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.
  • milin 7y ago
    jfrog's artifactory has nice support for python https://www.jfrog.com/confluence/display/RTF/PyPI+Repositories https://www.jfrog.com/confluence/display/RTF/PyPI+Repositori...
    • fjp 7y ago
      We use this where I work. I'm not the one managing it but I've never had a single issue as a user.
  • hathawsh 7y ago
    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 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.)
    • uranusjr 7y ago
      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.
• yingw787 7y ago
  This question might already be answered already, but who owns the built packages? Source code is released by license, but I don't know whether licensing compiled packages naturally inherit the same license from source. What would GitHub do in the case of a `left-pad` situation? https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
• deleted 7y ago
  [deleted]
• ccleve 7y ago
  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 other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I'm glad that getting that artifact out wasn't an emergency. This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it's only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.
  • ccleve 7y ago
    Hey Microsoft, if you're listening, you should throw Sonatype or other Maven-related organizations a few bucks. They deserve it.
    • IceSentry 7y ago
      Just because Microsoft has a lot of money doesn't mean they can just throw it around. That's not how the world works...
      • yawaramin 7y ago
        They're literally throwing around money creating new coding tools, languages, buying GitHub, LinkedIn, ... if we were to debate the effectiveness of its spending, there would be a lot to talk about.
        • ecocentrik 7y ago
          I hope you're not serious. Very few companies do anything just for goodwill.
• deleted 7y ago
  [deleted]
• mceachen 7y ago
  Doesn'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 demo, it seems very much like Gitlab's CI pipelines.
  • paulddraper 7y ago
    > Doesn't this bifurcate the namespace of literally every packaging system they are supporting No. Unless you consider the URL the namespace, but it's not. E.g. I can download the deb "vscode" from https://packages.microsoft.com/repos/vscode https://packages.microsoft.com/repos/vscode Or I could download that it from a GitHub-user controlled URL, or someone's random website. The name of the package is still "vscode", regardless of what location it was fetched from.
    • jacques_chester 7y ago
      > No. Unless you consider the URL the namespace, but it's not. It is for docker images. `foo/bar` is implicitly `hub.docker.com/foo/bar`.
      • paulddraper 7y ago
        True. I think people are pretty well accustomed to that though. Dockerhub, AWS ECR, Google Cloud, etc.
        • jacques_chester 7y ago
          Yes and no. It affects software that's installed via things like Kubernetes pod definitions. You need to "relocate" images to the correct registry in that case. This is a sufficient hassle that one of my colleagues maintains an entire tool devoted entirely to this purpose: https://github.com/pivotal/image-relocation https://github.com/pivotal/image-relocation
• lonnyk 7y ago
  It's always odd to me that PHP is left out of things like this. What do these other package managers have that Composer doesn't?
  • kyriakos 7y ago
    Python is left out too. It's a beta release so maybe they are not done yet.
• whatever_dude 7y ago
  As someone else said, "GOOD."
• vladimir-y 7y ago
  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.
  • rustyfe 7y ago
    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.
• chimen 7y ago
  Good to see them catching up on GitLab in terms of features.
• franky47 7y ago
  While the technical side of the news is interesting, the organisational repercussions worry me. Microsoft (who owns GitHub) is already one of the largest tech companies, and I would not be surprised if this move was intended to weaken NPM and Docker in an attempt to acquire them. I fear a future where everything one requires to develop "socially" depends on a single super-entity. GitHub and VSCode were the first steps in that direction, and now package management. My guess would be for CI/CD to be next on their list, with more integration of Azure somehow (potentially under the hood).
  • tkahnoski 7y ago
    Microsoft has been in this game for a while with Visual Studio, TFS, and other tools. The same strategy is just now catching up to a larget set of better tools. IBM I believe tried to do this with their 'Rational' tool line and they're still buying into the game (UrbanCode).
  • memmcgee 7y ago
    That would make sense as a worst case scenario but I'm not sure the evidence suggests that's the route they're going. If they wanted to acquire a CI/CD product, they would've bought Travis when it was being shopped around for a buyout.
    • vn-ki 7y ago
      But they already have CI. See azure pipelines.
  • keytarsolo 7y ago
    I'm glad you brought up Docker, but I think this is a move against GitLab, more than it is against NPM or Docker. Lots of us use GitLab at work because it's such a complete product. Source code, container registry, CI/CD, Issues (via GitLab or Jira), Maven repository, NPM repository, etc. etc. Microsoft is trying to build out GitHub so that they can more effectively compete for GitLab's corporate customers. Since buying GitHub they've added many of GitLab's key features to GitHub and these are some of the biggest adds so far. You might be right that this hurts NPM and Docker, but I think it'll hurt GitLab more.
• Qerub 7y ago
  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.
  • meddlepal 7y ago
    GitHub Actions?
    • Qerub 7y ago
      Hah, I had forgotten about that. Now they just have to integrate all the services and provide opt-in public traceability for source -> action(s) -> registry.
• peterwwillis 7y ago
  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.
  • brazzledazzle 7y ago
    They have Actions which can function as a basic CI.
• localhostdotdev 7y ago
  debian packages are also supported it seems: https://github.com/git-lfs/git-lfs/packages/5789 https://github.com/git-lfs/git-lfs/packages/5789 and https://github.com/alteregofun/firsty/packages/2953 https://github.com/alteregofun/firsty/packages/2953 found a ruby one: https://github.com/wintron/hola/packages/4057 https://github.com/wintron/hola/packages/4057 (yes! got it working)
• dang 7y ago
  Blog post at https://github.blog/2019-05-10-introducing-github-package-registry/ https://github.blog/2019-05-10-introducing-github-package-re....
• PureParadigm 7y ago
  I'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 the content would still be accessible.
  • deleted 7y ago
    [deleted]
  • ilaksh 7y ago
    There have been a few decentralized GitHub projects, but they've been largely ignored by developers. For example gittorrent or axic/mango or gitchain. When I have tried to promote them I've been downvoted. It seems pretty strange to me.
  • acdha 7y ago
    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 you can guarantee that participating won’t blow your ISPs data caps, interfere with other use, etc. Abuse is the other huge problem: think about what happens when you’re hosting some BLOBs and the FBI shows up at your door because someone uploaded some kind of contraband and some of it was available from your IP address. How many people are going to setup completely independent hosting accounts to avoid fallout from something like that which happens so regularly? The closest thing which comes to mind is the Debian mirror network and that is something of a historical fluke, predating centralized hosting being possible, and scoped to a much smaller set of more trusted participants. That also hits the big problem that even with a fair amount of infrastructure backing it, it’s hard to match the user experience of something like Github or NPM so the most likely case is spending a lot of time in hard problems but not overcoming the basic economics, as seems to be happening to IPFS.
• Roritharr 7y ago
  Please consider adding a Satis replacement for PHP Packages!
• bitfox 7y ago
  This is one of the services I was looking for. I'm curious to see how to community will react. Thanks for sharing!
• keerthiko 7y ago
  I'm really loving the way in which Gitlab and Github are looking to diversify their value-add offerings and auxiliary services without sacrificing any existing basic git functionality or UX, and without aggressively directly competing on the same feature set. This makes it less of "gitlab or github?" and allows developers to more easily decide to use just one for each project based on whichever service better focuses on the project's primary long-term goals. If you find yourself in a 2-way split market on a core offering, I think this strategy by both parties is net beneficial for everyone rather than trying to directly compete on all the same features and offerings.
• _bxg1 7y ago
  There's something slightly concerning about ceding responsibility for distributing the world's open-source projects from a family of strong independent repositories to a centralized platform owned by a tech giant.
  • sho_hn 7y ago
    Yes, but that's not a new concern - to some, GitHub has always represented an anathema to what git was supposed to be and bring. Centralization at a proprietary vendor, instead of open systems interacting. Then locking people in further by network effect and adding centralized products around git. That it's become so popular many people equate GitHub with git adds insult to injury. I completely understand why this all happened (centralization is just so easy and convenient; federation is hard), and it was probably inevitable in its timeframe, but I also wish it wasn't so. It's not quite what we imagined when we made the leap to dscms in the early aughts. All the good stuff is still in there, though, and it's still as possible as ever to do different things, so it's not a bleak situation.
    • beenBoutIT 7y ago
      *When the tech giant is Microsoft.
    • tedivm 7y ago
      When Linus introduced git he didn't seem to care at all about decentralizing from a political standpoint, just from a "I can work on this from my laptop without an internet connection" point of view.
      • toyg 7y ago
        That's the thing - git was fundamentally a tool borne with an asynchronous workflow in mind: I work on X, Alice works on Y, Bob works on Z, and the eventual merging (which might happen days or weeks later) should be as simple as possible - without worrying about who checked out what. Git was dropped in the "distributed VCS" bucket, but decentralization was a secondary effect of the workflow Linus wanted to achieve. GitHub then took the server-side bits of git, and effectively built a web-based interface with social features on top. Git itself is still very much a decentralized tool (just add a new remote and off you go), only the social GUI is centralized. It would be cool if somebody could build "Github over P2P" (I guess with a bit of blockchain, because hype). At that point the entire stack would be fully decentralized.
• pornel 7y ago
  I worry about npm now. The huge public registry everyone loves is run off investor's money and subsidized by npm's private registry product. But npm has recently changed their nice-people-matter CEO to a now-print-money dude, so I suspect investors' patience has run out. And now GitHub went directly after the one thing that npm is supposed to be making money on.
  • ne01 7y ago
    I guess this is the risk of working on a product that could be easily added as a feature to a much more popular product. But, hey, Dropbox is still successful.
  • cjbprime 7y ago
    I suppose a less anxious view is that we just diversified away from the ecosystem risk from what was looking to be the start of an implosion of npm.
  • soulofmischief 7y ago
    I don't worry about npm. I for one can't wait to move to a different registry.
    • ssalka 7y ago
      Same. Was hoping this would be an alternative to NPM, but it just builds on top of it
      • shusson 7y ago
        It's an alternative to the NPM registry.
        • soulofmischief 7y ago
          Yes, parent confused me... It is entirely orthogonal from NPM, correct?
• sebringj 7y ago
  This will eat into npmjs.com.
• systematical 7y ago
  How did this launch without composer support?
• CaliforniaKarl 7y ago
  From my perspective, it would be awesome if this could (in the future) be used to properly-host Debian and RHEL packages (extending of course to their derivatives, like Ubuntu and CentOS). I wouldn't expect that to compete with platforms like EPEL, but I think it would be great for easy distribution of programs that aren't in those wider places.
• wintorez 7y ago
  This is fantastic! No more `npm link`!
• didip 7y ago
  This is fantastic news!! I wish they will extend the offering to pypi hosting in the future. Is this available on the Enterprise offering?
• vemv 7y ago
  An useful intermediate step, but ultimately, a wrong move. Packages will keep having the essential problem that there's no guarantee whatsoever that the package was derived from the advertised source. Plenty of chance for delivering malicious code.
• burtonator 7y ago
  ... looking forward to the Hacker News post in 4 years about how Github has really lost their way and how they're now super evil. Remember this when you guys all rush to sign up for their new services because it's easier for you now ;)
  • jeanlucas 7y ago
    Meh, look at npm right now. I prefer this switch even if it means switching again in four or six years.
• vmware 7y ago
  Thanks for sharing This Package Registry.. I am Dotnet Developer, and working for Coupon Sites and create so many sites <a href="http://www.visualstudioprofessionalpromocode.com">visual http://www.visualstudioprofessionalpromocode.com">visual studio promo code</a> <a href="http://www.office2019promocode.com">office http://www.office2019promocode.com">office 2019 promo code</a> <a href="http://www.vmwarefusionpromocode.net">vmware http://www.vmwarefusionpromocode.net">vmware promo code</a> <a href="http://www.micropromocodes.com">microsoft http://www.micropromocodes.com">microsoft store promo code</a>
• yes_man 7y ago
  Is centralization of open source a good thing for the world or not? This thread seems to be overwhelmingly positive. And in the end we all will be critisizing it if all package repositories will be handled by a single entity. And that entity that is being applauded here in this case happens to be the most valuable corporation in the world right now. Healthy skepticism seems to be a disappearing attribute in the tech world
  • ilaksh 7y ago
    I suspect part of it is the Microsoft fanboy effect. Also, people strangely do not seem to be aware of the potential of truly decentralized p2p technologies to provide alternatives.
  • neurotrace 7y ago
    Seriously. I love Github but I don't know how to feel about a megacorp becoming the de facto source for packages in the open source ecosystem. It could be great but many of us thought that consolidating all of our social activities under the Facebook umbrella was going to be great
  • rich-tea 7y ago
    As usual it will take a disaster for people to realise it was a bad idea. Microsoft tried to destroy Linux in the past. Literally. Linux is what gave us git in the first place, and docker, and so much technology that we love today. Oh how quickly the past is forgotten when convenience is on the table.
    • frizkie 7y ago
      What about GitHub makes people more likely to use Windows? Or less likely to use Linux?
• fouc 7y ago
  Everyone, if a programming language you use already has a good package registry (like ruby has rubygems), I would be extremely wary about switching to github. Don't put all your eggs in a large company's basket.
  • nirvdrum 7y ago
    Oddly enough, before gemcutter and the refreshed rubygems.org, GitHub used to serve gems. IMHO, it was the easiest way to publish gems and it had a built-in namespace system where your username was prefixed to the gems (e.g., my Rails fork would be "nirvdrum-rails"). It took a while to clean up the mess when GitHub decided to close down its gem server. Workflows needed to be adapted, dependency lists updated, and so on. I'm certain there are still gems that never made the transition. GitHub is a different company now than they were a decade ago, so this may be less of a cautionary tale and more of a blip in their history. The JS package management space is interesting in that its primarily hosted by a private company, in contrast to Ruby's being funded by a non-profit. Betting on GitHub still running its package server in a decade may very well be safer than betting on NPM still being around.
• willcodeforfoo 7y ago
  This reminds me of GitHub’s beginnings when they were the easiest way to publish a Ruby gem
• hestefisk 7y ago
  It looks really cool. The only fear I have is the impact of mono culture if everyone starts using the same repo and it gets compromised. Having a topology of many different repos would make open source less prone to this kind of risk. That said, would be nice with a pkgsrc solution!
• tantalor 7y ago
  Can somebody explain the technical accomplishment here? What's new about this? Github already hosts source. What do they mean by "package"? Is it just source? I don't get it.
  • seaish 7y ago
    With the npm example, you can tell npm to use github's package repo instead of npmjs.com, and install from or publish to that one instead. Basically another npm, but the same command line app.
    • tantalor 7y ago
      Why is that useful?
      • ht85 7y ago
        One use is that you can point to any commit, but npm will only have versions that were explicitly released to it. Another reason would be having a few private packages and not wanting to manage an entire npm account for them.
  • ht85 7y ago
    Packages are different. For npm, you might publish your source 1:1 if you have a very vanilla setup, but a typical package in npm contains a built version of the code while the repo contains source, documentation, tooling, etc. Package versions are also created explicitly and tend to contain many changes, whereas repos are commit/branch based.
• torbFan 7y ago
  This is already a thing in GitLab?
• numbsafari 7y ago
  Excited to see someone other than JFrog and SonaType in this space. Personally, I think the major cloud providers are missing an opportunity by not doing the same.
• deleted 7y ago
  [deleted]
• noisy_boy 7y ago
  Now all that remains for Github to do is to add a build platform as alternative to Jenkins and a deployment framework. Source code, build platform, artifact storage and deployment - all co-located.
  • ToFab123 7y ago
    Azure Pipelines? https://azure.microsoft.com/en-us/services/devops/pipelines/ https://azure.microsoft.com/en-us/services/devops/pipelines/
    • noisy_boy 7y ago
      It looks interesting though has the extra Azure dependency. Jenkins doesn't have any such requirements.
  • josegonzalez 7y ago
    GitHub Actions?
    • noisy_boy 7y ago
      I'll explore it further. Seems like it is in public beta stage right now.
• bobquest33 7y ago
  Where is for python
• bobquest33 7y ago
  I did not see packaging for python
• dzonga 7y ago
  funny thing for js or well maybe npm you could already consume packages from github by just sayaing ```npm i -S @githubusername/bozopackage
• nevrthepfhor 7y ago
  You have to authenticate to github just to install a public package with maven? What a joke.
• plandis 7y ago
  So we are in the “extend” phase of Microsoft’s standard strategy? Can’t see how Microsoft replacing Maven is a good thing.
  • pluma 7y ago
    Any recent examples of Microsoft using EEE? All examples I can think of are from the 90s or very early 00s.
• tarasmatsyk 7y ago
  Awesome! I wish pypi was there too
• tech_tuna 7y ago
  Watch out Nexus and Artifactory, I've been commenting about this for a long time (on reddit). With the advent of Bitbucket Pipelines, GitLab CI and finally GitHub actions, I knew it was only a matter of time before package management was added as well. This is fantastic, I love the idea of one stop shopping for source control, CI/CD and a package registry.
• sanbor 7y ago
  If a government gets ssl certs of github then it will possible to MITM and distribute infected deps on millions of projects.
  • eitland 7y ago
    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?
    • sanbor 7y ago
      Yes, but instead of having two pwn 5 now they just have to pwn 1.
      • eitland 7y ago
        Still don't get it, if you pwn any of the above it is game over for a 10-30 percent of all computers. Same with GitHub packages, you'll have the possibility to a large number of projects, but far from all IMO.
• nathan_f77 7y ago
  I'm working on a SaaS service for developers, so I've built some API client libraries using openapi-generator [1] (using my OpenAPI specification.) The hardest part (by far) has been signing up for all of these different package manager services and figuring out how to release the libraries. Java and Maven was particularly difficult. It sounds so nice to be able to release all of my packages on one centralized service. I hope they support PHP and Python soon. [1] https://github.com/OpenAPITools/openapi-generator https://github.com/OpenAPITools/openapi-generator
• ksec 7y ago
  >Github CDN Does any one know if this is actually their own CDN with PoPs around the world, of do they really mean Azure ( Microsoft ) or Fastly, which they were using at one point?
  • anticensor 7y ago
    Dedicated instances in Azure cloud.
• pythonist 7y ago
  This 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 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.
• kostarelo 7y ago
  Centralisation is indeed to be concerned. I really had hopes for https://open-registry.dev https://open-registry.dev.
• nurettin 7y ago
  No pip registry?
• timwis 7y ago
  I was really hoping they would take advantage of also housing the code to mediate some of the trust issues we've seen in npm: specifically, being able to prove a binary was generated from this source code. Although I imagine that's tricky because then the build process would need to be run by them and be exposed as well..
• diggan 7y ago
  It's a really nice project overall, having a registry that supports many different projects and run by a company that today is good, is always nice. But we been here before. We trusted npm and now they are trying to squeeze out a profit, and it ruins it for the users. I'm happy to be proven wrong, but every for-profit company that runs a package registry, eventually stagnates, and ends up implementing things that are not for the users, but for their own profits. I think package management, especially for open source, should not be run by for-profit entities. We need to have something similar to public utilities, where the community funds the registry itself, and the community can own it as well, where the only changes allowed, are changes that are good for the users. This is not that. npm and docker are already run by for-profit companies, so this move by GitHub just adds another centralized package registry for those. It's not worse, by it's not better either. I'm a bit mad about the RubyGems part though, as RubyGems is a community project, and they are trying to make it not so, making it worse. What I'm currently working on, is how I think a Open Source Public Utility would look like. I just submitted a Show HN to show it off, you can see the submission here: https://news.ycombinator.com/item?id=19885502 https://news.ycombinator.com/item?id=19885502 Website is https://open-registry.dev https://open-registry.dev It's basically a community funded decentralized package registry, where the community funds it, and is a part of the ownership of the registry, handled via a governance followed by the contributors. All the finances, development and planning is happening in the open, and Open-Registry is committed to never making changes that are for increasing profits, only changes for making the service better for users. Please, if you have some free minutes, check it out and write down some feedback. We might not be the perfect package registry over night, but I'm hard at work getting as close as possible, without compromising the user value for it.
  • lewisjoe 7y ago
    First of all, thank you for building something like this. I like the idea of a decentralized, open registry. That said, the market's moving towards a universal registry for package management, across tech - npm, docker, linux packages, jars etc. With that perspective, GitLab's initiative (https://about.gitlab.com/direction/package/ https://about.gitlab.com/direction/package/) is something I'd likely prefer. The software's open-source and deployable, which means the software's fate isn't tied to that of a single company. It's already ironic enough, that the world's biggest collection of open source projects is managed by a single closed-source software - GitHub.
• polskibus 7y ago
  Does this mean the death of npm the company?
• jeremiahlee 7y ago
  I agree the artifacts should live alongside the code that produced them. But doesn’t Github killing npm, Inc. and Docker, Inc. in one move indicate Github is too powerful and, therefore, a huge liability? We need decentralized solutions, not another monopoly.
  • vvpan 7y ago
    Interesting thought about decentralized solutions. No "napster of packages" out there?
  • andreineculau 7y ago
    100% agree with you. Take the JS world for instance, npm is many good&bad things, but one thing that was squeezed in the package.json spec is the ability to install packages from git repositories. And so, github already had a "package registry" for npm, and we publish npm packages to github without needing extra credentials, etc. Granted npm could add a command "publish-to-git", or allow setting the repository to a github url, but a simple tool like https://github.com/andreineculau/npm-publish-git https://github.com/andreineculau/npm-publish-git does the job (it's regularly used and tested within my current company TobiiPro https://github.com/tobiipro https://github.com/tobiipro).
• zyngaro 7y ago
  GitHub is amazing but is becoming the SPOF for the open source world.
• dom96 7y ago
  This is really cool. I'm excited to integrate it with Nim's package manager Nimble [1]. It will be a little strange though, since Nimble packages just need to be tagged in git and then you've got a release. It doesn't seem that GitHub implemented it this way. 1 - https://github.com/nim-lang/nimble https://github.com/nim-lang/nimble
• jermo 7y ago
  Seems like the Maven registry is susceptible to artifact hijacking. Say I wan't to install artifacts from two GitHub users. I would have to add these two Maven repositories: - https://maven.pkg.github.com/USER1 - https://maven.pkg.github.com/USER2 In that case USER1 can publish an artifact with the same groupId/artifactId as USER2 and my Maven will happily install it without suspecting anything. Another case - someone deletes their GH account and another user takes it: https://blog.sonatype.com/hijacking-of-a-known-github-id-go-bindata https://blog.sonatype.com/hijacking-of-a-known-github-id-go-... Docs: https://help.github.com/en/articles/configuring-maven-for-use-with-github-package-registry https://help.github.com/en/articles/configuring-maven-for-us...
  • soulofmischief 7y ago
    I'm not familiar with maven, is there an equivalent of npm's scope feature? As for account hijacking... I guess GH needs to track account deletions and append incrementing suffixes to usernames under the repository.
    • jermo 7y ago
      There is in Gradle 5.1+ but not in Maven, afaik. They are using Maven in their examples, however.
• sandGorgon 7y ago
  Will this have a container registry built in ? it mentions Docker, but not sure about the details. What about Docker image builds ?
• vbsteven 7y ago
  This is very interesting. Would this also support hosting artifacts for closed source projects without having to add every user to my Github org? For example, I am working on a SaaS product that can be optionally self hosted. I want to provide docker images and maven artifacts for the self hosted portion but since they are closed source I don't think they belong on Maven Central or Dockerhub.
• agentofuser 7y ago
  Helping decentralize package managers is Protocol Labs' top priority for IPFS in 2019[1]. Seems very prescient now. Hopefully this gets adopted soon enough, while it's still easy to batch-export stuff out of registries. I really don't want MS owning the most popular editor, git host, "linux desktop", and universal package manager in the world. Edit: oh, and programming language (typescript is eating javascript.) [1]: https://github.com/ipfs/package-managers https://github.com/ipfs/package-managers
• brianzelip 7y ago
  Here’s a really good episode by the package manager-focused podcast The Manifest, about Maven with Brian Fox. https://manifest.fm/6 https://manifest.fm/6
• miguelmota 7y ago
  Really cool. Hope Microsoft keeps the momentum going with releasing new features on Github.
• CallMePK 7y ago
  I will now be waiting for them to add Python package support.
• dfilppi 7y ago
  No Python?
• carapace 7y ago
  I think it's worth considering a different "angle" or emphasis on software releases. This went by the other day: "Software Heritage and GNU Guix join forces to enable long term reproducibility" https://news.ycombinator.com/item?id=19699031 https://news.ycombinator.com/item?id=19699031 So that's an interesting "4 dimensional" way to think about your software packaging, eh? When does it make sense to "push" your code to the long-term archive? And this: "The Great Adobe Purge of ’19" https://news.ycombinator.com/item?id=19863481 https://news.ycombinator.com/item?id=19863481 and https://news.ycombinator.com/item?id=19888429 https://news.ycombinator.com/item?id=19888429 Here the issue is apparently licensing.
• exabrial 7y ago
  This is extraordinarily generous of github, but I don't think having a hundred maven repositories is a good idea. We have central and a process for putting signed artifacts there
• WorldMaker 7y ago
  I'm very curious how this will compare/contrast with Azure Artifacts. Will it interoperate well with Azure Artifacts? Will there be guidance for when to use GitHub Package Repository and when to use Azure Artifacts?