One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.
Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right?
> ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings]
I mean, the JavaScript development community has -collectively- decided on a huge bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?
The people who ask for more proprietary features (or should I say anti-features) in Github are encouraging lock-in inside of Github. Github ought to be a hub. I'd like to emphasize on the hub part as it should be one hub out of many. It should not be the center of the software universe any more than AT&T/IBM/Microsoft/Google/Facebook/Uber.
So, I heartily agree that vendor lock-in is bad. [0] However, git doesn't handle mailing lists, or issue trackers, or hands-off repo push access control, or.... So, if you're going to do more than just serving git repos, you're almost certainly going to have to do these things yourself, and you very well might end up doing them in a way that differs from how everyone else is doing them.
I mean, as long as you can get complete exports of the data in the important non-git bits, who cares, right?
[0] I'm STILL mad about how Hangouts turned out.
More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths
Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]
> ...coordination between go and github could implement something for deprecated repositories without changing anything in git.
A couple of things:
* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.
* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)
* Frankly, having a well-known file in your Git repo that contains meaningful tags seems far more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)
[0] Thanks for the documentation link, BTW! :D
I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many. Whoever decided it was OK to depend on that library should be able to follow it closely enough to say when it cannot be depended on.
There are a lot of "if's" and many things might go wrong -- there's almost never 100% guarantee, but every mean that makes end product more reliable is a good idea.
"I feel like if you have so many direct dependencies that you can't keep tabs on them, you simply have too many."
Such number of dependencies is common when building custom Kernel/OS + application. Also, I've never mentioned direct dependencies, some are just tools to build tools. It wasn't event that big of a project -- a relatively small (~150 Mb) custom OS with Qt application for an embedded device.