Live data from Hacker News

GitHub Package Registry

github.com

221–230 of 389 posts

Re: GitHub Package Registry

#221
post #188
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…

I've had great success finding devs for my company on SO. I would hate to see it go away.

LinkedIn and Github didn't go away.

Re: GitHub Package Registry

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

I don't worry about npm. I for one can't wait to move to a different registry.

Same. Was hoping this would be an alternative to NPM, but it just builds on top of it

Re: GitHub Package Registry

#223

Earlier quoted context omitted.

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

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.

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

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

Re: GitHub Package Registry

#224

Earlier quoted context omitted.

I'm not convinced this means the death of Maven Central, but I'll start publishing to both either way.

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.

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.

Re: GitHub Package Registry

#225

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…

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

Re: GitHub Package Registry

#226
post #178
post #152

Earlier quoted context omitted.

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.

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

You might be interested in Fossil.

Tickets and the wiki are stored as part of the repo and don't depend on a completely separate web interface.

Re: GitHub Package Registry

#227

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.

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.

Re: GitHub Package Registry

#228
post #129

Earlier quoted context omitted.

Hopefully something along these lines will also be added to Gitab. I share your concerns, but I've also long had the feeling that both NPM and Maven are a security disaster in the making. Having the dependencies being published from the same place that stores the actual code, gives me a little hope that things will improve from the security and design perspective.

...by adding a single point of failure?

No, my thoughts are that we need better mechanisms to validate our dependencies.

So far I believe that Maven and NPM have failed to deliver on that front.

The dependencies being resolved from the code store provides a decent mechanism to resolve that issue.

But as long as it's being done on closed software, it's going to be hard to move towards a standard.

Re: GitHub Package Registry

#229

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

Bit like security alerts which were initially just JS and Ruby. Indeed odd.

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.

Post reply on HN