Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Package Registry

github.com

Post reply on HN
Print view View original

381–389 of 389 posts

Re: GitHub Package Registry

#381

Post by takeda »

blondin wrote: post #239
mikepurvis wrote: post #24

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

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.

What would it be? Go doesn't have any packaging system.

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.

Re: GitHub Package Registry

#382

Post by WorldMaker »

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?

Re: GitHub Package Registry

#383

Post by Alexander473 »

pornel wrote: 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.

Actually, it has never felt natural to me to publish a Node.js package to two web sites, both Github and NPM. Moreover, when Google lands me on NPM's web site I prefer to navigate right away to Github. If this new thing from Github is going to replace NPM so that there's only one place for that matter - I would not mind.

Re: GitHub Package Registry

#384

Post by brazzledazzle »

symlinkk wrote: post #94
brazzledazzle wrote: post #82

Earlier quoted context omitted.

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.

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.

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.

Re: GitHub Package Registry

#385

Post by Lord_Zero »

GordonS wrote: post #338
phreack wrote: post #227

Earlier quoted context omitted.

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.

Quite a few repos point people towards Gitter instead.

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.

Re: GitHub Package Registry

#386

Post by Lord_Zero »

GordonS wrote: post #361
your-nanny wrote: post #351

Earlier quoted context omitted.

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.

Re: GitHub Package Registry

#387

Post by your-nanny »

GordonS wrote: post #361
your-nanny wrote: post #351

Earlier quoted context omitted.

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?

this assumes that posting it to GitHub is actually intended to facilitate its use by other people.

Re: GitHub Package Registry

#388

Post by your-nanny »

owaislone wrote: post #374
your-nanny wrote: post #225

Earlier quoted context omitted.

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…

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.

Re: GitHub Package Registry

#389

Post by owaislone »

your-nanny wrote: post #388
owaislone wrote: post #374

Earlier quoted context omitted.

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…

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

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