I think it's reasonable to expect you to set up your GOPATH accordingly, if you want the layout to be internal and specific and deviating from the discovery mechanism. There is no reason, why a tool couldn't fetch your internal git-repository to the subpath of $GOPATH that corresponds to your public mirror. I also advocated elsewhere for go get having the ability to use some kind of mirror for fetching, to solve the "code can vanish" objection why people want vendoring (e.g. your company runs a mirror of all your used open source code and you use "go get --proxy=internal.company.net github.com/some/package" and go-get fetches it from " internal.company.net/github.com/some/package" or something like that).
In any case, I don't think that these things are outweighing the pros of go's decentralized approach to namespacing and hosting; the disadvantages have relatively obvious solutions. On Fri, Nov 25, 2016 at 12:48 PM, Mariusz Gronczewski <xani...@gmail.com> wrote: > > > On Friday, November 25, 2016 at 12:10:56 PM UTC+1, Axel Wagner wrote: >> >> It is pretty simple: >> >> * If you actually *fork* a project (not what github calls a "fork", but >> "create a repo with a different set of maintainers"), *that is a different >> package*. It will contain different code and have a different mantainer. So >> it is a feature, that go get won't work on it OOTB. To make it work, you >> have to commit making and using it as a different package by changing >> import paths. People pretend like forking should take over another persons >> package, but that just doesn't make sense, that's the whole point of >> identifying packages by import paths and having a discovery mechanism that >> reconciles conflicts by relying on the DNS. >> * To prepare a PR, just add your "fork" (I hate githubs nomenclature >> here) as a second remote in $GOPATH/src/github.com/upstream/project. >> Commit and push to your fork, then create the PR. When done, optionally, >> delete your fork. >> >> The two things are very different processes. One is "being dissatisfied >> with a project so taking over maintainership" (what the FOSS-community >> calls "forking") and the other is "publishing a copy of a repo with your >> patches so that the maintainer can pull from it" (what github calls >> "forking", but is actually just "using the decentralized nature of git as a >> VCS). Don't mix the two up and everything makes sense. >> > > I get it but often I have a problem where "main" place of development is > our internal repository (and for various political reasons github can't be > used for that) but we'd still want to open source that code and not have to > deal with path translation. > > There is also the "I want to show it to someone but they are > git-illiterate" case > > > >> >> >> On Fri, Nov 25, 2016 at 11:40 AM, Mariusz Gronczewski <xan...@gmail.com> >> wrote: >> >>> But then go get github.com/me/project will be non-functional ? >>> >>> 2016-11-25 11:35 GMT+01:00 Ian Davis <m...@iandavis.com>: >>> > This is how to do it with a git repository: >>> > >>> > http://blog.campoy.cat/2014/03/github-and-go-forking-pull-re >>> quests-and.html >>> > >>> > >>> > On Fri, Nov 25, 2016, at 10:31 AM, Mariusz Gronczewski wrote: >>> > >>> > Hi, >>> > >>> > So let's say there is a project, living under path >>> github.com/local/project. >>> > Project is neatly divided into a bunch of packages and uses recommended >>> > absolute paths: >>> > >>> > package main >>> > >>> > import ( >>> > "github.com/external/dep1" >>> > "github.com/local/project/config" >>> > "github.com/local/project/backend" >>> > "github.com/local/project/frontend" >>> > ) >>> > >>> > >>> > and packages inside of it also use that: >>> > >>> > package backend >>> > >>> > import ( >>> > "github.com/external/dep3" >>> > "github.com/external/dep4" >>> > "github.com/local/project/config" >>> > "github.com/local/project/backend/nosql" >>> > "github.com/local/project/backend/sql" >>> > "github.com/local/project/backend/dummy" >>> > ) >>> > >>> > package frontend >>> > >>> > import ( >>> > "github.com/external/dep5" >>> > "github.com/external/dep6" >>> > "github.com/local/project/config" >>> > "github.com/local/project/backend" >>> > "github.com/local/project/frontend/html" >>> > "github.com/local/project/frontend/pdf" >>> > ) >>> > >>> > ...how does one contribute to it ? >>> > >>> > If I just go and fork it and do a bunch of changes across packages >>> then I >>> > can't test it because everything will be under "github.com/me/project" >>> so >>> > deps will come from the "wrong" place. >>> > >>> > If I go and find-replace everything now I can work in peace but any >>> diff or >>> > pull request from it wont make any sense as now it will contain wrong >>> paths >>> > >>> > If I use relative packages then things like `go test` complain about >>> local >>> > imports and wont run. >>> > >>> > Surely there is a better method than "just glue it with some symlinks" >>> ? >>> > >>> > Cheers, Mariusz >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to golang-nuts...@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to a topic in the >>> > Google Groups "golang-nuts" group. >>> > To unsubscribe from this topic, visit >>> > https://groups.google.com/d/topic/golang-nuts/if5H8kRAT30/unsubscribe. >>> > To unsubscribe from this group and all its topics, send an email to >>> > golang-nuts...@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Mariusz Gronczewski (XANi) <xan...@gmail.com> >>> GnuPG: 0xEA8ACE64 >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
