GitHub repo bundles?


(Eric Lindblad) #1

Are there any community comments on designation or presentation of information, e.g., in a GitHub hosted 3rd party Go repository’s README.md file, where that organization’s sibling and/or golang.org/x/ repos (as dependencies) may accompany the specific repo’s clone or download?

This is effectively what some other coding languages might refer to as a bundle.


(Holloway) #2

Do you meant by distribution via git bundle? Not within my radar. AFAIK, it is for offline-single file transfer and rarely used due to various packaging services available.


(Eric Lindblad) #3

perhaps this topic’s title is misleading

where a GitHub organization’s repo C includes that organization’s repos A and B

or, a GitHub organization’s repo contains a complete (or partial) copy of the repo golang.org/x/sys

that Contents, for lack of a better term, might not appear in the given repo’s README.md file


(Eric Lindblad) #4

enthusiastic use of the like button screwball


(Jakob Borg) #5

I’m trying, but I have to admit I still don’t have any idea what you’re asking. I feel there is context missing… I’m not sure what a repo containing repos is (git submodules? Go vendoring?) nor how a readme ties into this or constitutes a bundle of some kind.


(Eric Lindblad) #6

perhaps this topic’s title is misleading

The term bundle, was misappropriated from CPAN, furthermore, used incorrectly, a CPAN bundle will download and install dependent modules, similar as running go get -u golang.org/x/tools/... will download and install golang.org/x/net, if the latter is not already present.

PackageManagementTools (Golang wiki)

Having read the above my overt annoyance has disappeared over the content included in certain GitHub hosted 3rd party Go repositories’ README.md files; consequently I am not soliciting any further comments on this topic.


(Holloway) #7

Oooh, you mean the inclusive packaging that turned into vendor solution and now abandoned. It used to be a practice (before vendor) but usually specified in README.md. Otherwise, an issue ticket would be wise.

The problem was the rolling release for some dependencies were fast, wide, and uncontrollable, breaking the existing repo almost every time. A workaround is to internalize the dependencies (hence packing them together).

Using this approach has other problems: bloated repo, and complete reliance on developer’s trust that they don’t temper the dependencies and pull updates from the upstream (e.g. go-bindata incident, before the author’s github account was taken over).

I was one of the developer but preferred to move up to module due to issues with the said approach. I suspect the removal was to discourage folks to head back to that direction again.

p/s: are there developers who still doing such distribution practices? It was a horrible maintaining experience. It’s worse than migrating to go module.

At least you’re on the receiving side. :yum:

My give/receive stats difference is good enough to make a startup commercial.