I'm fine with namespacing and I see benefits for it for deps, just it would be nice to have something inbetween absolute path and "../../something" (like "$ROOT/packagename") for package-local "subpackages" that are not designed to be standalone ones (like in my case it is usually a package holding few structs shared between other packages).
> 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). Yeah it would be nice. Maybe in the form of .dotfile with just a list of aliases for each part of the address, grouped into "profiles". That would allow to for example have a empty profile (or just one that maps your public code to github and leaves private for internal repos) for normal work and "github-down" profile that points it to internal mirror in case there is something wrong with 2016-11-25 13:00 GMT+01:00 Axel Wagner <axel.wagner...@googlemail.com>: > 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-requests-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. > > -- Mariusz Gronczewski (XANi) <xani...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
