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.
I think if they required a user or org-namespaced package name, you'd get that. For example, if 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.
Basically because it's all just github, the package author and publisher are intrinsically linked because the package repo is directly associated with the code repo. In NPM, there is not any way to directly ensure the publisher and package author are the same because they're different systems.
If you can just point at the github registry, and run `npm publish`, does that really solve the problem?
NPM's major problem is there's no official link between the package and the repo, any code/branch can be published, and unless I'm missing something, this doesn't really solve that issue.
OTOH GitHub is already in the position to require that only accounts that have 2-factor auth enabled can publish to public repositories. You can already require on organization level that only users who have 2FA enabled can be members of the org, which is great feature for orgs that host private code on GitHub.
AFAIK most cases where npm etc. have been compromised are scenarios where maintainer of a popular package re-used a password, and the password became compromised in some unrelated hack. Other attack vectors (compromising access tokens on maintainer's computer, compromising 2FA, compromising a git repo) really are a notch harder.
Even if these hacks are not the fault of npm per se, they make them look bad, and looking bad security-wise is really really something you don't want to happen to you when your whole business model is founded on user trust (public package repo).
There can be a link, if you prefer to write your dependencies down that way in package.json. See Git URLs¹ and GitHub URLs².
There are some challenges, though. If the repository requires a build step to derive a package from it then the author has to provide the proper package.json lifecycle hooks, e.g. a prepare script. Also, there's presently no git/hub-install support for a package nested inside a monorepo.
That does not change with this github registry. It's simply moving the binary storage. But as long as Github is not enforcing reproducible builds, or letting users pulling down build environments, the statue quo is still the same as today.
This is one of the things I love about Packagist. Technically Composer doesn't care where the source is from, but the official Packagist repository actually just uses Github as the storage and CDN for downloads. You have to link a repo to publish it, and Packagist will only publish source committed to your repo (no build steps, etc). Packagist then uses the zipball downloads for each package for it's source.
Downside of this approach is that almost any PHP project requires you to configure Composer with a personal access token for Github due to the amount of API requests causing rate limiting. Folks sometimes end up wondering why Composer needs an API token to download otherwise public code. (https://getcomposer.org/doc/articles/troubleshooting.md#api-...)
Composer/packagist has done many things right: namespaced packages, and downloads straight from VCS to name a few.
I wouldn't consider the Github personal token to be an issue either. It's a one-time setup per device, and my server (which only pulls code) never needed one, because it uses the lock files to download the exact commit/tag, and this significantly reduces the number of API calls made.
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.
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.
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...
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.
> MS's core competency has always been developers.
As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract.
Classically, MS has been good to developers who agree to be chained to their platform, but has made life extremely difficult for developers who want or need to be platform independent.
Platform vendors and developers will forever have conflicting interests.
I don't think developers should place too much trust in any platform vendor. (Apple and Swift, Apple and Metal, Google and AMP, Google and Dart, Amazon and AWS... the list is endless.) Their interests are fundamentally at odds with ours.
Platform vendors benefit when developers are locked in by network effects. Developers maximize their value when their skills are transferable.
And that goes for Github and its package registry. Concentration of power is problematic.
Except that in the commerical software world, you can't stay independent with "purity".
The costs of supporting multiple cloud providers is still a cost. K8S, Docker, Pulumi, Packer are starting to reduce that interoperability gap, but it's still a friction.
I've moved to .NET on Ubuntu for our current project (I'm an Engineer Manager/Architect, but the team is C#). It's been remarkably smooth and low friction.
So it's a balance, the interests of a platform vendor are of course that you stay on their platform. But currently there's enough competition that it's still a buyers market.
AWS is getting a bit too powerful, Azure is doing a good job of keeping MS shops in the MS world, but GCP is disappointing.
In the abstract, what would best serve developer interests is if platforms are as compatible as possible, especially in their superficial details. That minimizes switching costs, both in terms of what it takes to port real software from one platform to another, and in terms of what a developer must learn to apply what they already know when working with a new platform.
Taken to an ad absurdum conclusion, developers want all platform vendors to coordinate in order to minimize switching costs. Of course there are lots of good reasons such a level of coordination will never be realized. :)
In the meantime, there will always be efforts to create adapters which generalize the interfaces of multiple platforms and put them behind a common wrapper interface. But while such interoperability efforts serve developer interests, they work against the interest of vendors in encouraging platform lock-in.
The dynamic isn't pure in terms of real product offerings because vendors also understand that portability provides value to developers, and so some vendors will provide at least some portability in order to differentiate themselves. But I maintain that the fundamental interest structure is unchanging.
>As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract.
Yes, Active X, Windows, Java etc, and god knows how many awful things they did I cant remember them all. But years later Bill Gate decide to donate his wealth to good cause. Not only is this not a PR / Marketing Stunt, he is actually using his time and energy running it. That alone halves whatever hatred I have had.
Ever since they lost the Smartphone OS race ( if you consider they were even part of it ), I don't consider M$ a monopoly or threat any more.
And given the amount of Good things they have done since new CEO took helm, WSL, and now WSL2, VS Code, .Net Fully Open Sources with MIT license, ditching IE ( God that feels good ) , Direct X RT, along with lots of Research put out, I think it is worth reevaluating that hatred against M$ we once had.
We have no lasting friends, no lasting enemies, only lasting interests.
Back in the 80s, IBM was evil, Apple and Microsoft were good. I have an "I HATE IBM" badge from a very early computer show.
MS was mainly known for its languages and its apps, more than the OS. IBM PCs still came with CP/M or PCDOS (MSDOS).
Then when Windows 3 came out, MS started to act like IBM but on steroids, thinking they owned the "stack" (as it was). OS/2 was the last attempt to extract the "PC compatible" world from the Windows domination.
Then IE6 and ActiveX ensconced MS in the enterprise. What used to be "you won't get fired for buying IBM" became "you won't get fired for buying MS because there's no choice".
The onset of the web and competitors in MS's dominant space (well except for apps, Office still rules the world) and the demise of the Ballmer years (especially the death of their mobile/phone ecology) means that MS is now actually doing what IBM did about 15 years ago when they adopted Linux.
Microsoft started acting like IBM from the moment the DOS licensing was agreed with IBM. Incredibly naive on IBM's part, or perhaps they simply expected to sell so few machines it wouldn't matter. After all the first PC was deliberately crippled to stay away from more expensive IBM kit.
MS were acting like mini IBM throughout the 80s, and before the mid 80s had very much gained a negative reputation globally. It was against Microsoft, not IBM, that was the usual target of complaint when the first AT clones were coming out - 84? 85? I think Windows 1 was about the same time. Certainly enough of a reputation to be amazed they were still collaborating with IBM to produce the first OS/2, again around the mid 80s.
A large part of that in the late 1970's IBM was under anti-trust investigation. They had to make some changes in behavior to prevent bad results. Much of the PC would have been different/closed if IBM wasn't afraid of what lawyers would do.
When you have that much money it isn't possible to donate it all at once.
Fraud in charities is a real thing. There are a lot of "charities" that do some good work, but primary exist for the benefit for the benefit of someone. Often the primary purpose is to hide bribes: the CEO's spouse is a high government official. It is very easy to get mess up in such a charity and end up not doing well with your money.
The other problem is 90B is to much money for any charity to handle at once. Any charitable program that has a lasting (and thus useful) impact will take time. Even if the charity sets up a trust, there is nothing to stop the CEO from raiding that trust in latter years. Several charities started good, but over time have slowly - and legally - morphed into something that is very different from what the founders intended.
Staying in charge of his money is the best way to ensure that it is used well.
Pure speculation, it would not surprise me to wake up someday and see MS has bought Stackoverflow. Given their direction of integrating the entire developer experience, it would make sense. MS is upgrading technical docs across the board, organizing and linking to SO content would make sense.
It is still really unorganized in many ways. The worst thing, I think, is search results still frequently list obsolete MSDN pages higher...and, btw, the new branding is not MSDN, but docs.microsoft.com.
They still have a long ways to go, with the typical problems of a large organization tackling a large, kind of amorphous, project.
docs.microsoft.com PM here - thanks for the feedback! It takes some time to update all our search results across the two major search engines. Given that some pages have less traction than others, the more obscure content sometimes still is indexed as if it's coming from MSDN.
We have moved most of the library to docs, with redirects in place, so hopefully you won't get too many 404s. If you do - feel free to report them here: https://aka.ms/sitefeedback, and we'll address them.
I'm genuinely asking, not meaning to poke if it's Bing - I use DDG but just don't have a feel at all for what's most popular after the obvious one.
Wikipedia has just 7% market share left for the second, and the rest - thinking about it's probably one that's popular in China and unheard of elsewhere?
Considering Verizon has stated their Yahoo and AOL properties are worthless[0], it's probably Bing and the search engines that rely on it (including DDG).
Funny thing, you're describing exactly why you're not assuming a global perspective. Forget about a first, the world is fragmented. To be global is precisely to cater to individual locations around the world.
Question: Why is Offline documentation and the Help Viewer in Visual Studio 2017 still horribly broken? I keep it around for when I don’t have internet access but it’s next to useless. Why keep up the pretence? (In comparison, the CHM and DocEx from VS6 through VS2008 work perfectly and are very reliable)
What particular aspect of it is broken? Genuinely asking the question, because I want to make sure we address major issues in the customer experience that you have.
Massive amounts of duplicated content. Broken images and stylesheets. I’ve downloaded all content but pressing F1 on a symbol in VS informs me the content is only available online.
Truth, I was at SO in Manhattan for a JS meetup a couple times and all the desktop computers were PCs with Dell monitors.Not a single Mac in sight. Have a feeling they weren't running linux either since Stack Overflow is .NET I believe.
I remember many many years ago listening to the Stack Overflow podcast which was Jeff Atwood and Joel Spolsky talking, in real time, about them creating Stack Overflow.
IIRC it uses ASP.Net MVC or something like that, and might have been the first and/or biggest site using it?
> running linux either since Stack Overflow is .NET I believe
It is a matter of taste and I'm sure these guys (Atwood/Spolsky) love Windows to work on, but with .NET Core (we started porting when the first stable ASP.NET Core came out), we ported/migrated everything from Windows/MS (SQL server, Windows Server, AD, etc) to Linux + MySQL/Postgresql on ASP.NET Core.
I guess it's what you are used to, but everything is faster, smoother, more stable/consistent and easier to manage now. I would never go back.
In light of StackOverflow looking for a new CEO, layoffs in the past year and a half, $68 million in venture capital looking for a return, and Joel Spolsky's connections to Microsoft, this might actually happen.
I've also gotten the impression that StackOverflow's recruiting product isn't doing so well. It seems to be a few hundred dollars a month for a single job posting, but the results for recruiters are apparently mixed.
Pretty sure it was developed entirely on the MS stack. Jeff Atwood had a few posts about it. At the beginning it was literally one Windows Server machine.
StackOverflow for Teams seems like a really hard sell too. $5-10/user/mo is pretty steep, especially for a service that needs a significant-size userbase to "work".
We use StackOverflow for Teams with a small team (<15 developers) and it’s been great. While I’m sure our revenue alone won’t make it profitable, I think it’s a product that can work with teams of all sizes. Don’t knock it till you’ve tried it.
You might say StackOverflow careers isn’t doing well, but it is literally the only jobs listing outside of this website that I look at. The ability to get a succinct email within a chosen SALARY RANGE and being able to select remote only is AWESOME.
If I remember correctly, my team of four was quoted at $13k/yr for the StackOverflow job posting / recruiting solution.
It's probably worth it for companies with greater hiring needs than ours, but LinkedIn (begrudgingly), and ZipRecruiter have provided enough quality candidate-flow for far less money that it doesn't make any sense for our uses.
> All they need now is a place to get coding questions answered
I think Github issues has already started doing that. Personally, I've been finidng more help from Github issues than Stack Overflow, plus I find myself asking questions or submitting bugs on GH a lot more than asking something on Stack Overflow. In fact, I've not asked anything on SO for years now.
I think YMMV on this, cause I also know of a lot of repos that explicitly close any issues that are support requests because they fill up the issue list so quickly. I think having it separate as in SO is still going to be the move unless there's some big re-organization of how Issues work.
This is quite true but it's boggling why neither Github nor its competitors haven't added a 'questions' tab to public repos where people are explicitly allowed to ask questions, and have them answered by maintainers or other users.
Which is usually a ghost town. Maintainers of small libs usually don't even monitor SO. Issues is the fastest way to get high visibility and get a question answered quickly since newcomers usually read GitHub issues to see if there are any serious things to worry about before using the package.
If I post code to a GitHub, I'm happy for you to use it, and I'm happy to learn about bugs in the code. But what obligates me to facilitate support, or respond to support requests? People should grow up.
Plainly you're not obligated to, but if you want to actually grow the userbase it makes sense. If you really don't want to help with (reasonable) support requests, then an alternative is to make that abundantly clear in your README.
> People should grow up
Not sure what this childish quip adds to your otherwise sensible comment?
I personally will pass on any project/lib that has a bunch of unanswered issues, or a bunch of auto closed stale issues. Unless the project is big enough to have an active SO or Gitter community.
Issues aren't used as people generally use SO. Questions like "how do X". Most people use issues to report bugs, request features and most prominently contact the authors when things either don't work as expected or the software lacks documentation about how certain things are supposed to work. I as a user and maintainer of OSS packages prefer such questions in issues than on some random site like SO which I won't be monitoring. Issues is a great place to consolidate all the knowledge around a package. Also, most of such questions can be considered as bugs, feature requests or just plain lack of documentation.
sure ...except that a lot of support questions can be completely irrelevant to your project, because the users aren't competent programmers. it's a big time suck, and people happily demand help, and then not even bother to thank you for the hour of your time you spent solving their problem--which was ultimately due to them not paying attention, or having basic donain knowledge.
I'm all for giving. I happily write tutorial blog posts, but I don't feel obligated to give more help than I already gave.
I see what you mean but questions like these are not what I was really referring to. I do get them from time to time on my repos and I point them to where they can get help which usually is some mailing list, docs or some other related project. Also, my quality of life as a maintainer has dramatically improved since I stopped caring about maintaining clean list of GH issues. I'm fine with people opening tons of them and a lot them being open for a long time. I'll get to them when I can as I don't feel obliged anymore to answer all those questions or implement new features.
You jest, but Microsoft seems to have really taken Ballmer's message to heart lately. Ballmer was on-the-nose about needing a strong developer community; he was just terribly misguided about how to actually get one going :)
The term "social network" has become too vague in 2019. You will have to append a purpose to each one. ie. Yelp is a social network for food, LinkedIn is a social network for professionals, and GitHub is another for developers.
Each one will serve a niche which is much harder to supplant because there's a common purpose. In contrast, when people think of Facebook, people just associate it as 'the' social network but not one for a special purpose.
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?
Watching the live stream now (https://live-stream.github.com/). Will likely use the Docker support near immediately. Hoping Singularity will be supportable as well.
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.
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.
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.
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.
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:
Hey. You can probably find my name in each of the zendesk comments/issues. Thiago posted a few for me. I have been very vocal about what I feel needs to be done through my sales leads (my client has a EEU subscription).
GitLab released integrated packaging back in 2016 - starting with a Docker registry - and adding Maven and NPM in 2018. You can find our plans for adding further packaging capabilities on our public packaging roadmap https://about.gitlab.com/direction/package/
We are also embarking on making package management more secure and auditable for the users of packages with a Dependency Proxy https://about.gitlab.com/direction/package/dependency_proxy/ GitLab users will be able to block and delay packages that are suspect and trace where vulnerable packages were used. This will increase performance, cost efficiency, and the stability of your tests and deployments.
> GitLab released integrated packaging back in 2016 - starting with a Docker registry - and adding Maven and NPM in 2018.
No, first version with "NPM support" (see my other comment as why I don't consider it being "supported") was gitlab 11.7, end of january 2019. I was really looking forward to this and were following your verdaccio (an open source npm registry) thread closely. Development then made a 180 and chose to re-implement rudimentary support for npm on top of your current package abstraction instead.
I love Gitlab, but I think it's good GitHub is taking the threat serious and that we finally have some real competition in this space and not just one dominant player.
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.
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.
There's nothing required from PSF to create own repo. I created one myself on S3, all you need is then just update pip.conf to use it. Pip also has functionality to support primary repo and a backup, so they don't need to make their repo a pass through to PyPI, pip basically can be configured to look up first the custom repo and if package is not found then fallback to PyPI.
Hosting a Python package index is much simpler, just dump the files in a web accessible directory with a directory listing and specify it with `--find-links`.
PyPI has no closer relationship to Python than the other options to their respective language. Similarly to others PyPI also runs out of an http server. There really is nothing tied to Python.
GitHub, at least from what I've seen publicly in the past, uses all the ones they support except maybe Java/Maven; I've never seen anything about them internally using Python.
So, it's not really all that surprising of an initial set of choices for them to make.
Github has traditionally been a Ruby shop and once you are a Ruby shop, you can use Ruby to do anything that you could use Python for so there is no need to touch Python other than may be data science. That means they would have built a lot of expertise in Ruby and comparatively very little with Python. So it's understandable that they are able to add support for Ruby before python. It must have been easier to do for them and also been much easier to "dog-food".
That said, I'm sure Python, Go, Rust and other languages will be supported very soon.
Yes but in future Go will most likely use a package server that will act like a proxy, a cache and way to verify packages. There will be many implementations. Some engineers at Microsoft are building one called Athens. Go team will release one as well. Github could release yet another one.
Notice how you were able to call out the de facto package manager for those languages, but didn't for Python? I would imagine supporting the various Python package managers in use would be a bit annoying.
pip is the default package manager for Python, and while anaconda knows how to install from PyPI, you just pip install things into anaconda environments. So, the answer is "pip".
Third party proprietary tools like bintray/artifactory manage to do it without too much trouble. Honestly, there aren't really that many formats to support for Python these days— if you don't mind kicking some legacy to the curb, sdist, bdist, and whl pretty much covers it— any other splintering of the ecosystem is on the tooling side, but all the tools that matter still generate one or more of those three formats as the archive.
Actually bdist is legacy is not even used anymore you basically use whl (bdist_wheel), generate packages for specific platform and also provide sdist (source) so people that use platform you forgot about still can use your package. If you're lazy you can just upload sdist.
There's only one - PyPI used by pip, and you can run it on a basic web server.
There only other that I heard is anaconda, but that's made by 3rd party (not affiliated fir PSF), it is not just Python but also R since it targets scientific community. I also believe it is primarily used by windows users.
It is packaging for scientific tools that happen to also have python.
Edit: from another comment I see that underneath anaconda apparently uses PyPI for python packages (I didn't know, since I never used it) so it is not even a proper repo, just an abstraction to PyPI (and possibly whatever R is using)
people may be reading too much into this. notice there is no go either? maybe because we often tend to pip install and go get directly from github repos and releases? so whether they are working on proper integration or not, nothing is being missed here.
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?
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.
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.
2,5 Billion, with money from oversees on which they otherwise would be heavily taxed. They bought a game studio with significant growth potential at 20x its annual profits, but maybe even more important, they bought 54 Million and growing user accounts on a diversity of platforms, of often very young captive users, easily convertible into Microsoft accounts, a number which was poised to expand rapidly.
Indeed, Microsoft has sold and added 100M more Micecraft licenses and accounts since.
From an account acquisition point of view alone, which fairly often is the main driver of these transactions, the deal was a steal. I'd estimate the value of a fresh user account in a desirable demographic to be around $250 for Microsoft. Even the short term projected revenue would be close to $10.
Microsoft projected the deal to pay for itself in 1 year, and while not having followed the case up close, chances are it did.
It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.
Their support is the worst. I anticipate a 4 day turn around if I ever need to contact them. Scary really.
Their Gradle plugin is pretty bad too; kinda ironic given their prominent position in the Android and Java community. But then, Gradle itself is crazy town so it's hard to blame them too much.
I tried it years ago and it didn't offer signed packages at the time. I ended up just using ansible to build my own rpm/deb repos on a server given to us by a University:
I think you've been somewhat unlucky. I've been releasing some code on Maven Central for a while, and while original setup did take some time and was a bit confusing at times, once all keys were in place deploy works with a couple of short steps. It is true the packages do not appear immediately, but I imagine serving this much content requires heavy caching, so I can understand that, and the wait times aren't that outrageous either.
That said, would be interesting what Github's effort comes to. It's always better to have alternatives.
Yea same here. There are way too many workflows already setup around Maven Central. People publish to it from Scala/SBT, Gradle, Clojure/Leiningen, Kotlin, etc. It's not going to be going anywhere any time soon.
Exactly. It’s nice to have competition in the Java package space aside from Maven, Jfrog Artifactory and Nexus. It will take time to build up network effects for Github but if they make a good product I could see it happening eventually. We use Artifactory where I work and the generic aspect of it plus the ecosystem integrations are super nice. I can publish docker images, regular zip files, jar files, Python packages etc and use the same tooling for all of that. GitHub should really push for the one-stop-shop approach here because I feel like that’s going to be their major competitive advantage. That’s where Gitlab has been playing too so I wouldn’t be surprised to see a similar product from them in the near future.
Where do you think most of those project's are managing their code? And of those, what percentage are already publishing releases on GH? I'm willing to wager the migration will be much faster than you think.
I tried publishing a side-project to Maven Central for a few hours, only to give up and publish to Bintray in minutes.
I'm willing to admit I was probably doing it wrong, but I'm glad it forced me to look at other options. There are definitely easier methods of package/publishing out there, and GitHub package registry sounds awesome.
Publishing to Maven Central comes with a bunch of requirements (https://central.sonatype.org/pages/requirements.html) may be seen as a burden to packagers, but is certainly a delight for end-users of those packages.
All packages are GPG signed, come with companion source and javadoc artifacts, and are guaranteed a certain amount of other metadata in the POM. There are "easier" repositories (like Bintray jcenter) but anyone who has used something from there that didn't include sources or proper licensing information soon comes to appreciate why it is that Maven Central (and not jcenter) that is the center of the Java ecosystem.
Unfortunately the GPG signing is worthless because there's no way of attaching trust to each key. So each package has been signed, but anyone could have issued the keys, so an attacker could easily do the same.
Also, not all artifacts have sources and javadoc. Most do but some certainly don't.
So continuing this way GPG is worthless in general. Most of the keys you can't verify in person so there is no trust whatsoever. In this case Sonatype is verifying key for you. They will check if your key belongs to you and you are in control of your organization. Otherwise package would not be accepted.
I may be wrong but source and javadoc are requirements. Maybe there are some old packages without it, but new ones should be complete.
Maybe they're historic and now it's a requirement, or maybe it's prereleases or something, but I have certainly seen some in the past. First one I can dig up: https://repo1.maven.org/maven2/com/google/protobuf/protobuf-...
The newer versions certainly do have sources and javadoc, but you can't assume their presence for everything.
You could for example opt for TOFU. Then at least you’d be protected against a malicious takeover unless the attacker manages to access the maintainers private key. That’s been a pretty common issue in the recent past.
> So each package has been signed, but anyone could have issued the keys, so an attacker could easily do the same.
Not true. The GPG signature means the key belongs to an account with access to the group id (namespace, usually a domain), and that sonatype has verified the group id belongs to the original admin account for that group id.
It's not a lot of guarantees, but you cannot just generate a GPG key, sign a package, and publish to maven central.
Anyone can issue a GPG key claiming to be whatever identity they want though. I've uploaded artifacts to Maven Central before and they didn't do any specific verification of the signing key - so if it just matches the domain that is no protection at all.
Just compare how well organized and neet are the packages in Maven Cetral to mess in JCenter. JCenter is full of inconsistent trash. I can imagine people pushing packages there for testing and then just forget about them.
Not everyone and not all of them, of course. But while I was looking around to figure out which repository to choose as my main, JCenter has put me off. I still can't understand how people can easily trade convenience for quality.
Disagree about being the death of Maven Central - they are different beasts.
- Central has a global namespace of artifacts. com.google.guava is the same for everyone. This will probably stay the default of open-source libraries.
- GitHub Package Registry has a per-user maven repository, so a local namespace (https://maven.pkg.github.com/OWNER). This is likely to be used by companies internally.
In order to use GH Registry instead of Central, I would have to add a dozen maven repositories to my settings.xml. I doubt many developers will be up for that.
> It will mean the death of Maven Central, about which I have mixed feelings
I don't see it as such. A key reason that this offering from GitHub (and the corresponding one for GitLab) is useful is that it simplifies the enterprise stack - things that will never get posted to Maven or npm or DockerHub in the first place.
From the announcement:
> Packages in GitHub inherit the permissions of the repository, and you no longer need to manage third party solutions and sync team permissions across systems.
This impacts locally hosted Nexus repositories. The artifacts that I build for my team that currently get pushed to internal systems can now live along side the source code repository.
From the "What our customers are saying":
> GitHub Package Registry has allowed us to spend more time solving hard problems, and improving patient care. Since it uses the same permissions and security as the rest of GitHub, we spend less time managing multiple accounts, ACLs, and on-premise infrastructure, which leaves us with more time to code what matters!
That is exactly where it is useful.
For maven central, I am pleased to have the governance and management of those systems be part of my deployment chain for third party libraries and I will continue to prefer to pull something from Maven Central rather than somewhere else whenever possible.
What? Maven Central is here to stay. It will be here even after a nuclear war. Jitpack does the same as GitHub Package Repository (or even simpler) and Maven Central is still here. I don't see why this would change anything.
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.
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.
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.
I'm a little bit anxious because the pricing has not yet been published. Both GitHub Actions and package registry will be free for public repositories but it is not yet known how much it will cost for private repositories after the beta.
They said they expected the package registry to be included in all paid plans. So it's only going to cost you anything if they decide to raise prices for everything across the board, it seems.
Namespaces in general are a mess. I want domain validated namespaces; github.com/example.com/, docker.io/example.com/, @example.com/, facebook.com/example.com, twitter.com/example.com, etc.. Whoever owns the domain owns the validated namespace. I doubt it'll ever happen though since (IMO) namespace squatting makes services look more popular than they are and some sites (ex: GitLab) already allow usernames with dots in them.
As for registries, I didn't like Docker's URLs when I first started, but now I'm convinced it's a good scheme. I can "own" my (domain) namespace by running my own registry. The implementation could have been a bit better though:
* The daemon should allow the user to force the use of a local mirror / cache as a registry.
* The daemon should pass full URLs to the registry for requests (https://github.com/docker/distribution/issues/1620).
That way something like Sonatype Nexus could be used as a local caching proxy for all Docker images and could automatically request images from (public) upstream repositories without any additional config.
The new TLDs make perfect identities / namespaces and there are plenty to go around.
Even with @author, my github username is someone else on npmjs. So installing “@me/module” will either get my module or the other guys depending on sources it would seem.
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.
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.
388 comments
[ 0.29 ms ] story [ 291 ms ] threadhttps://help.github.com/en/articles/about-github-package-reg...
Supports NPM, Docker, Maven, Nuget, RubyGems
The ability to provide any one with access to the repo access to the packages created from it removes an often frustrating management step.
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.
I think if they required a user or org-namespaced package name, you'd get that. For example, if 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.
NPM's major problem is there's no official link between the package and the repo, any code/branch can be published, and unless I'm missing something, this doesn't really solve that issue.
AFAIK most cases where npm etc. have been compromised are scenarios where maintainer of a popular package re-used a password, and the password became compromised in some unrelated hack. Other attack vectors (compromising access tokens on maintainer's computer, compromising 2FA, compromising a git repo) really are a notch harder.
Even if these hacks are not the fault of npm per se, they make them look bad, and looking bad security-wise is really really something you don't want to happen to you when your whole business model is founded on user trust (public package repo).
There are some challenges, though. If the repository requires a build step to derive a package from it then the author has to provide the proper package.json lifecycle hooks, e.g. a prepare script. Also, there's presently no git/hub-install support for a package nested inside a monorepo.
¹ https://docs.npmjs.com/files/package.json#git-urls-as-depend...
² https://docs.npmjs.com/files/package.json#github-urls
A simple tool like 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).
We publish npm packages to git tags that get installed exactly the same as packages received from a registry, no build step necessary.
Downside of this approach is that almost any PHP project requires you to configure Composer with a personal access token for Github due to the amount of API requests causing rate limiting. Folks sometimes end up wondering why Composer needs an API token to download otherwise public code. (https://getcomposer.org/doc/articles/troubleshooting.md#api-...)
I wouldn't consider the Github personal token to be an issue either. It's a one-time setup per device, and my server (which only pulls code) never needed one, because it uses the lock files to download the exact commit/tag, and this significantly reduces the number of API calls made.
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.
As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract.
Classically, MS has been good to developers who agree to be chained to their platform, but has made life extremely difficult for developers who want or need to be platform independent.
Platform vendors and developers will forever have conflicting interests.
Eg their main focus for .net Core has been multi platform - ie the last 3-4 years!
Visual Studio Code.
And on browsers they are building what will probably be a better Chromium than Google's Chrome, in the new Edge.
Platform vendors benefit when developers are locked in by network effects. Developers maximize their value when their skills are transferable.
And that goes for Github and its package registry. Concentration of power is problematic.
The costs of supporting multiple cloud providers is still a cost. K8S, Docker, Pulumi, Packer are starting to reduce that interoperability gap, but it's still a friction.
I've moved to .NET on Ubuntu for our current project (I'm an Engineer Manager/Architect, but the team is C#). It's been remarkably smooth and low friction.
So it's a balance, the interests of a platform vendor are of course that you stay on their platform. But currently there's enough competition that it's still a buyers market.
AWS is getting a bit too powerful, Azure is doing a good job of keeping MS shops in the MS world, but GCP is disappointing.
Taken to an ad absurdum conclusion, developers want all platform vendors to coordinate in order to minimize switching costs. Of course there are lots of good reasons such a level of coordination will never be realized. :)
In the meantime, there will always be efforts to create adapters which generalize the interfaces of multiple platforms and put them behind a common wrapper interface. But while such interoperability efforts serve developer interests, they work against the interest of vendors in encouraging platform lock-in.
The dynamic isn't pure in terms of real product offerings because vendors also understand that portability provides value to developers, and so some vendors will provide at least some portability in order to differentiate themselves. But I maintain that the fundamental interest structure is unchanging.
Yes, Active X, Windows, Java etc, and god knows how many awful things they did I cant remember them all. But years later Bill Gate decide to donate his wealth to good cause. Not only is this not a PR / Marketing Stunt, he is actually using his time and energy running it. That alone halves whatever hatred I have had.
Ever since they lost the Smartphone OS race ( if you consider they were even part of it ), I don't consider M$ a monopoly or threat any more.
And given the amount of Good things they have done since new CEO took helm, WSL, and now WSL2, VS Code, .Net Fully Open Sources with MIT license, ditching IE ( God that feels good ) , Direct X RT, along with lots of Research put out, I think it is worth reevaluating that hatred against M$ we once had.
We have no lasting friends, no lasting enemies, only lasting interests.
MS was mainly known for its languages and its apps, more than the OS. IBM PCs still came with CP/M or PCDOS (MSDOS).
Then when Windows 3 came out, MS started to act like IBM but on steroids, thinking they owned the "stack" (as it was). OS/2 was the last attempt to extract the "PC compatible" world from the Windows domination.
Then IE6 and ActiveX ensconced MS in the enterprise. What used to be "you won't get fired for buying IBM" became "you won't get fired for buying MS because there's no choice".
The onset of the web and competitors in MS's dominant space (well except for apps, Office still rules the world) and the demise of the Ballmer years (especially the death of their mobile/phone ecology) means that MS is now actually doing what IBM did about 15 years ago when they adopted Linux.
To quote Vonnegut, "So it goes".
MS were acting like mini IBM throughout the 80s, and before the mid 80s had very much gained a negative reputation globally. It was against Microsoft, not IBM, that was the usual target of complaint when the first AT clones were coming out - 84? 85? I think Windows 1 was about the same time. Certainly enough of a reputation to be amazed they were still collaborating with IBM to produce the first OS/2, again around the mid 80s.
Did he? Bill Gates has consistently been getting richer according to Google, and now has a staggering 90B.
Fraud in charities is a real thing. There are a lot of "charities" that do some good work, but primary exist for the benefit for the benefit of someone. Often the primary purpose is to hide bribes: the CEO's spouse is a high government official. It is very easy to get mess up in such a charity and end up not doing well with your money.
The other problem is 90B is to much money for any charity to handle at once. Any charitable program that has a lasting (and thus useful) impact will take time. Even if the charity sets up a trust, there is nothing to stop the CEO from raiding that trust in latter years. Several charities started good, but over time have slowly - and legally - morphed into something that is very different from what the founders intended.
Staying in charge of his money is the best way to ensure that it is used well.
We have moved most of the library to docs, with redirects in place, so hopefully you won't get too many 404s. If you do - feel free to report them here: https://aka.ms/sitefeedback, and we'll address them.
What's the second major search engine?
I'm genuinely asking, not meaning to poke if it's Bing - I use DDG but just don't have a feel at all for what's most popular after the obvious one.
Wikipedia has just 7% market share left for the second, and the rest - thinking about it's probably one that's popular in China and unheard of elsewhere?
0; https://www.nbcnews.com/tech/tech-news/verizon-signals-its-y...
Baidu in China. Yandex in Russia. Google in the US. Not sure for India and Latin America.
The poster was probably thinking of Bing though, which is ironic because it's maybe less used than these.
If we are to believe these stats, Google is at 3% market share in China. It's basically non existent. http://gs.statcounter.com/search-engine-market-share/all/chi...
Microsoft has developers everywhere in the world, who need docs. There are major search engines besides Google and Bing.
IIRC it uses ASP.Net MVC or something like that, and might have been the first and/or biggest site using it?
It is a matter of taste and I'm sure these guys (Atwood/Spolsky) love Windows to work on, but with .NET Core (we started porting when the first stable ASP.NET Core came out), we ported/migrated everything from Windows/MS (SQL server, Windows Server, AD, etc) to Linux + MySQL/Postgresql on ASP.NET Core.
I guess it's what you are used to, but everything is faster, smoother, more stable/consistent and easier to manage now. I would never go back.
I've also gotten the impression that StackOverflow's recruiting product isn't doing so well. It seems to be a few hundred dollars a month for a single job posting, but the results for recruiters are apparently mixed.
It's probably worth it for companies with greater hiring needs than ours, but LinkedIn (begrudgingly), and ZipRecruiter have provided enough quality candidate-flow for far less money that it doesn't make any sense for our uses.
I think Github issues has already started doing that. Personally, I've been finidng more help from Github issues than Stack Overflow, plus I find myself asking questions or submitting bugs on GH a lot more than asking something on Stack Overflow. In fact, I've not asked anything on SO for years now.
> People should grow up
Not sure what this childish quip adds to your otherwise sensible comment?
I'm all for giving. I happily write tutorial blog posts, but I don't feel obligated to give more help than I already gave.
Each one will serve a niche which is much harder to supplant because there's a common purpose. In contrast, when people think of Facebook, people just associate it as 'the' social network but not one for a special purpose.
FWIW I'm using GitLab CI for the cross-platform build pipeline of PhotoStructure (8 jobs over 3 OSes), and it's really great.
Maven: https://docs.gitlab.com/ee/user/project/packages/maven_repos...
NPM: https://docs.gitlab.com/ee/user/project/packages/npm_registr...
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/10050 https://gitlab.com/gitlab-org/gitlab-ee/issues/9164 https://gitlab.com/gitlab-org/gitlab-ee/issues/9104
We are also embarking on making package management more secure and auditable for the users of packages with a Dependency Proxy https://about.gitlab.com/direction/package/dependency_proxy/ GitLab users will be able to block and delay packages that are suspect and trace where vulnerable packages were used. This will increase performance, cost efficiency, and the stability of your tests and deployments.
No, first version with "NPM support" (see my other comment as why I don't consider it being "supported") was gitlab 11.7, end of january 2019. I was really looking forward to this and were following your verdaccio (an open source npm registry) thread closely. Development then made a 180 and chose to re-implement rudimentary support for npm on top of your current package abstraction instead.
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.
There's no technical or political obstacle here.
https://pip.pypa.io/en/stable/reference/pip_wheel/#find-link...
You can also link directly to a package with `--find-links` if you specify an egg fragment, e.g. 'https://github.com/project/reponame/tarball/version#egg=pack.... (The version must match that in setup.py.)
Keep in mind it's in beta.
So, it's not really all that surprising of an initial set of choices for them to make.
That said, I'm sure Python, Go, Rust and other languages will be supported very soon.
There only other that I heard is anaconda, but that's made by 3rd party (not affiliated fir PSF), it is not just Python but also R since it targets scientific community. I also believe it is primarily used by windows users. It is packaging for scientific tools that happen to also have python.
Edit: from another comment I see that underneath anaconda apparently uses PyPI for python packages (I didn't know, since I never used it) so it is not even a proper repo, just an abstraction to PyPI (and possibly whatever R is using)
Installing directly from github is possible, but it works ok for a one off, if you have a package with your own dependencies then that doesn't scale.
It also covers source installations it doesn't work well for compiled.
What would GitHub do in the case of a `left-pad` situation?
https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
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.
Giving money to sonatype or somebody like that will be forgotten in a week by outsiders.
So does GitHub's package registry. In terms of ROI for dollars spent, that seems pretty good.
Indeed, Microsoft has sold and added 100M more Micecraft licenses and accounts since.
From an account acquisition point of view alone, which fairly often is the main driver of these transactions, the deal was a steal. I'd estimate the value of a fresh user account in a desirable demographic to be around $250 for Microsoft. Even the short term projected revenue would be close to $10.
Microsoft projected the deal to pay for itself in 1 year, and while not having followed the case up close, chances are it did.
It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.
[1] https://bintray.com/
Their Gradle plugin is pretty bad too; kinda ironic given their prominent position in the Android and Java community. But then, Gradle itself is crazy town so it's hard to blame them too much.
https://github.com/BigSense/vSense/tree/master/ansible/roles...
That said, would be interesting what Github's effort comes to. It's always better to have alternatives.
It looks like from that post they only support Docker, Maven and NPM right now so they also have some catching up to do in the genericization world.
I'm willing to admit I was probably doing it wrong, but I'm glad it forced me to look at other options. There are definitely easier methods of package/publishing out there, and GitHub package registry sounds awesome.
All packages are GPG signed, come with companion source and javadoc artifacts, and are guaranteed a certain amount of other metadata in the POM. There are "easier" repositories (like Bintray jcenter) but anyone who has used something from there that didn't include sources or proper licensing information soon comes to appreciate why it is that Maven Central (and not jcenter) that is the center of the Java ecosystem.
Also, not all artifacts have sources and javadoc. Most do but some certainly don't.
I may be wrong but source and javadoc are requirements. Maybe there are some old packages without it, but new ones should be complete.
Not true. The GPG signature means the key belongs to an account with access to the group id (namespace, usually a domain), and that sonatype has verified the group id belongs to the original admin account for that group id.
It's not a lot of guarantees, but you cannot just generate a GPG key, sign a package, and publish to maven central.
Not everyone and not all of them, of course. But while I was looking around to figure out which repository to choose as my main, JCenter has put me off. I still can't understand how people can easily trade convenience for quality.
- Central has a global namespace of artifacts. com.google.guava is the same for everyone. This will probably stay the default of open-source libraries.
- GitHub Package Registry has a per-user maven repository, so a local namespace (https://maven.pkg.github.com/OWNER). This is likely to be used by companies internally.
In order to use GH Registry instead of Central, I would have to add a dozen maven repositories to my settings.xml. I doubt many developers will be up for that.
Docs: https://help.github.com/en/articles/configuring-maven-for-us...
I don't see it as such. A key reason that this offering from GitHub (and the corresponding one for GitLab) is useful is that it simplifies the enterprise stack - things that will never get posted to Maven or npm or DockerHub in the first place.
From the announcement:
> Packages in GitHub inherit the permissions of the repository, and you no longer need to manage third party solutions and sync team permissions across systems.
This impacts locally hosted Nexus repositories. The artifacts that I build for my team that currently get pushed to internal systems can now live along side the source code repository.
From the "What our customers are saying":
> GitHub Package Registry has allowed us to spend more time solving hard problems, and improving patient care. Since it uses the same permissions and security as the rest of GitHub, we spend less time managing multiple accounts, ACLs, and on-premise infrastructure, which leaves us with more time to code what matters!
That is exactly where it is useful.
For maven central, I am pleased to have the governance and management of those systems be part of my deployment chain for third party libraries and I will continue to prefer to pull something from Maven Central rather than somewhere else whenever possible.
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.
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
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.
It is for docker images. `foo/bar` is implicitly `hub.docker.com/foo/bar`.
I think people are pretty well accustomed to that though. Dockerhub, AWS ECR, Google Cloud, etc.
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
You can sign up for the beta here: https://github.com/features/actions
Introduction: https://www.youtube.com/watch?v=_yPml1iTbmM
I'm a little bit anxious because the pricing has not yet been published. Both GitHub Actions and package registry will be free for public repositories but it is not yet known how much it will cost for private repositories after the beta.
As for registries, I didn't like Docker's URLs when I first started, but now I'm convinced it's a good scheme. I can "own" my (domain) namespace by running my own registry. The implementation could have been a bit better though:
* The daemon should allow the user to force the use of a local mirror / cache as a registry. * The daemon should pass full URLs to the registry for requests (https://github.com/docker/distribution/issues/1620).
That way something like Sonatype Nexus could be used as a local caching proxy for all Docker images and could automatically request images from (public) upstream repositories without any additional config.
The new TLDs make perfect identities / namespaces and there are plenty to go around.
Owns it for now. It’s a similar problem to TLS certs but with longer term consequences as people don’t generally expect published libraries to expire.
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.