Live data from Hacker News

GitHub Package Registry

github.com

371–380 of 389 posts

Re: GitHub Package Registry

#371
post #93

Earlier quoted context omitted.

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

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.

Re: GitHub Package Registry

#372
post #117

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.

We were contacted by NPM to switch our Enterprise account from self hosted, to hosted by NPM.

There is two problems with this for where I work.

1. What if NPM goes bust? what happens to our packages? 2. What if NPM gets hacked? what happens to our packages? 3. The increase in price was HUGE.. which was probably the reason for forcing us to migrate to their new cloud hosted option.

Look it's an open secret at this point that NPM is in trouble, it's fired a bunch of staff, other staff have quit. The new CEO is all about profit, and its just the beginning.

Here's what we did.

We spun up a nexus instance https://www.sonatype.com/download-oss-sonatype

It has a NPM plugin, so we get our private repo .. we host it ourselves.. it's exactly what we want.

Honestly if you're an Enterprise customer, this is something to consider

Re: GitHub Package Registry

#373

Earlier quoted context omitted.

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…

Doesn't Go already download packages from GitHub?

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.

Re: GitHub Package Registry

#374

Earlier quoted context omitted.

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

Please don't put support questions in issues!

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.

Re: GitHub Package Registry

#375
post #270

Earlier quoted context omitted.

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" wor…

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…

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.

Re: GitHub Package Registry

#376
post #242

Earlier quoted context omitted.

>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, h…

> But years later Bill Gate decide to donate his wealth to good cause. Did he? Bill Gates has consistently been getting richer according to Google, and now has a staggering 90B.

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.

Re: GitHub Package Registry

#377

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

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

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.

Re: GitHub Package Registry

#378

Earlier quoted context omitted.

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.

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.

There's no technical or political obstacle here.

Re: GitHub Package Registry

#379

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

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.

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)

Re: GitHub Package Registry

#380

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN