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.
GitHub Package Registry
221–230 of 389 posts
Re: GitHub Package Registry
#222I 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.
Re: GitHub Package Registry
#223Earlier 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.
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
#224Earlier 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.
Re: GitHub Package Registry
#225This 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.
Re: GitHub Package Registry
#226Earlier 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…
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
#227Earlier 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.
Re: GitHub Package Registry
#228Earlier 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?
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
#229Looks 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.
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.
Re: GitHub Package Registry
#230Now 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.