5 ms·

Many are starting to use GitHub as a registry for hosting packages, in this case Deco components[1]. GitHub should look into this, otherwise we get git repos w

by ihsw 10y ago

Many are starting to use GitHub as a registry for hosting packages, in this case Deco components[1]. GitHub should look into this, otherwise we get git repos with directories that are thousands in length. Certainly it makes sense to host published code on GitHub as well as in-development code. I could see it replacing the likes of NPM[2], Packagist[3], RubyGems[4], PyPI[5], etc. [1] https://github.com/decosoftware/deco-components/tree/master/.deco https://github.com/decosoftware/deco-components/tree/master/... [2] https://www.npmjs.com/ https://www.npmjs.com/ [3] https://packagist.org/ https://packagist.org/ [4] https://rubygems.org/ https://rubygems.org/ [5] https://pypi.python.org/pypi https://pypi.python.org/pypi

jswny 10y ago
This could work. There wouldn't be a need anymore for linking to the Git repo in an NPM package or similar. Maybe a special branch with a simple JSON file containing package data in the same repo as the main project.
- ihsw 10y ago
  Versioning and indexing becomes an issue -- this has to be entirely and completely separate from git repos and git branches. Playing with branches like that falls apart pretty quickly when you need to add real features that are expected by package maintainers.
consolelog 10y ago
http://bower.io/ http://bower.io/ does this in a sense by watching releases on a repository.
pierrec 10y ago
>GitHub should look into this, otherwise we get git repos with directories that are thousands in length. In a way, Github already looked into it extensively while helping resolve the issue where CocoaPods monopolized their servers and hit CPU rate-limiting. Whether it's abusive or not was already debated ad nauseum when it happened, but either way they came to a set of solutions which might help anyone else wanting to use Github for package management: http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Pos...

by ihsw 10y ago

jswny 10y ago

This could work. There wouldn't be a need anymore for linking to the Git repo in an NPM package or similar. Maybe a special branch with a simple JSON file containing package data in the same repo as the main project.

ihsw 10y ago
Versioning and indexing becomes an issue -- this has to be entirely and completely separate from git repos and git branches. Playing with branches like that falls apart pretty quickly when you need to add real features that are expected by package maintainers.

consolelog 10y ago

http://bower.io/ http://bower.io/ does this in a sense by watching releases on a repository.

pierrec 10y ago

>GitHub should look into this, otherwise we get git repos with directories that are thousands in length. In a way, Github already looked into it extensively while helping resolve the issue where CocoaPods monopolized their servers and hit CPU rate-limiting. Whether it's abusive or not was already debated ad nauseum when it happened, but either way they came to a set of solutions which might help anyone else wanting to use Github for package management: http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Pos...