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

The GitHub registry public beta is live

help.github.com

Post reply on HN
Print view View original

111–120 of 137 posts

Re: The GitHub registry public beta is live

#111

Post by hobofan »

quickthrower2 wrote: post #78
hobofan wrote: post #17

At least in the case of NPM (I don't know as much about the other ones): Doesn't that create a huge opportunity for hijacking attacks, where someone publishes a malicious NPM package in the default NPM registry under the scope identical to a Github organization/username?

That is an interesting idea, playing on people's confusion as to where to install from. And someone is going to put the super terse `npm i -g mytool` on their README.md page (because it's all about the easy installs isn't it!) and forget to say "change your registry to github" and boom!

Not even "someone". Exactly that command is available to copy to clipboard on the page of this new feature. Yeah, a small link to the instructions is printed underneath it, but most users - especially the ones that are new to package managers and the most vulnerable - will ignore that.

Re: The GitHub registry public beta is live

#112

Post by jayflux »

tacticus wrote: post #73
jayflux wrote: post #65

Earlier quoted context omitted.

There was a Go dependency that got deleted (repo removed) and screwed everyone else’s project up, so I’m not sure this is perfect either.

Which won't stop it happening with a package manager either. Even immutable repos are going to have fun with DMCAs.

npm hosted the packages so acted like a cache, the same didn’t happen when people deleted repos

Re: The GitHub registry public beta is live

#113

Post by orf »

andyfleming wrote: post #86
orf wrote: post #64

Earlier quoted context omitted.

Pipenv locks the VCS dependency to the commit, making pulling very fast.

Does it do a shallow pull or pull a tarball of the source?

Shallow pull. You can specify the github tarball URL if you’d prefer.

Re: The GitHub registry public beta is live

#114

Post by Crinus »

jolmg wrote: post #46
carapace wrote: post #36

FWIW, Software Heritage already has your github repos: https://www.softwareheritage.org/ https://hn.algolia.com/?query=Software%20Heritage&sort=byPop... And GNU Guix at least will transparently fallback to them: > Since Software Heritage archives source code for the long term, Guix can fall back to the Software Heritage archive whenever it fails to download source code from its original location. The way this fallbac…

You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Fire…

> I wish I could install Firefox or Chrome from a decade ago as easily as I can install the latest versions.

You can, on Windows. The secret is the system keeping backwards compatibility in mind for its core APIs, something that most desktop APIs on Unix (outside of X11) do not do.

Re: The GitHub registry public beta is live

#115

Post by asymmetric »

matthewbauer wrote: post #91
jolmg wrote: post #46

Earlier quoted context omitted.

You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Fire…

I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need…

Wouldn’t it be enough to checkout the commit where a-x.0 was updated, rather than the last known commit where a is at x.0? That way, if the packagr built successfully at that commit, you know it’s a good version.

We do something similar (and the way more manual) here[0].

[0]: https://github.com/dapphub/dapptools/blob/master/overlay.nix...

Re: The GitHub registry public beta is live

#116

Post by ageofwant »

bad_user wrote: post #97
ageofwant wrote: post #42

Earlier quoted context omitted.

git repos can be as immutable as you want. you just need to point your package manager to a commit or tag, instead of a branch head. if you are worried about a rebase, well you have that issue with any public artefact stores.

The point is that it's not your Git repo, usually, when talking of dependencies, so it's not really about what you want. SHAs can't be changed, but they can be deleted. And on GitHub, entire projects, usernames, orgs can be deleted. Or renamed. In case of a user rename, GitHub does maintain redirects for awhile. Until that username is taken by somebody else.

If that is a big concern you can fork. If you are building production systems with dependencies on eggs you can't find in pypi you probably should take control of those in your own copies. I can't recall once that I had to do that for things that I ask money for though... if its not in pypi its probably not worth using. And if it is useful, forking or just copying the module or package into your own code base takes care of any shifting dependencies.

So yea, does not seem to be a problem that actually exists.

Re: The GitHub registry public beta is live

#117

Post by oblio »

danShumway wrote: post #51
hn_throwaway_99 wrote: post #23

Earlier quoted context omitted.

If you are familiar with Nexus or Artifactory or Verdaccio, which all essentially let you have private NPM repos (among other formats like Maven, etc.), that's what this is.

What's the difference between publishing a binary file on Artifactory and linking to a binary file in a Github release[0]? Is Artifactory immutable? Or I guess that it handles versioning/publishing better? [0]: https://help.github.com/en/articles/linking-to-releases

Artifactory can also proxy stuff. It's widely used as a corporate proxy for public repos so that you don't rely on the whims of the internets.

Re: The GitHub registry public beta is live

#118

Post by oblio »

btown wrote: post #90
psadauskas wrote: post #82

Deja vu https://github.blog/2008-04-25-github-s-rubygem-server/ And then removed 16 months later: https://github.blog/2009-10-08-gem-building-is-defunct/ Hopefully this one lasts longer.

It’s incredible to read the casual tone of those postings. Ten years ago Github was just an amazing innovation that could just spin a service shutdown as an experiment - now everything it does is vital infrastructure for modern development.

It's also a service they launched in the first year as a company... I think they were still looking for an MVP at the time, I have no idea how anyone could compare the situations.

Re: The GitHub registry public beta is live

#119

Post by thefounder »

sooheon wrote: post #15
thefounder wrote: post #10

I like Go more. The git/hg/svn/bz repository is the "package". No custom (and central) "registry"

This is not unique to Go, every language I work with can use dependencies in this way.

I guess you don't work with many languages

Re: The GitHub registry public beta is live

#120

Post by thefounder »

atombender wrote: post #49
thefounder wrote: post #10

I like Go more. The git/hg/svn/bz repository is the "package". No custom (and central) "registry"

It's worth noting that Go is getting its own registry system soon, the Go Module Index [1]. [1] https://blog.golang.org/modules2019

You can use modules without a registry. It remains to be seen how many prefer a centralised registry
Post reply on HN