Hi, I've followed your idea, it seems that go team doing this purposely. But I don't think this is "completely reasonable". It seems like forcing project to put an assertion "Where I am". As our consensus, a good project is surely with "high cohesion", but never care "Where I am".
Imagine that if "go.exe" has an assertion [assert(GoRoot == "c:\go")] in function main. If we want to install golang in "d:\go", sorry, it doesn't work. You have to fork another copy of golang src, and make the change [assert(GoRoot == "d:\go")] as another project. It looks strange, and nobody wanna doing like this. 在 2017年11月16日星期四 UTC+8下午5:00:15，Axel Wagner写道： > > Hi, > > there are two things, people might mean, when they say "fork": > > a) The original meaning: Taking an open source project and adopting it, > maintaining your own changes. In this case, the forked package becomes a > different one. It has different code, maintained by different people so it > makes total sense, for it to have a different name. In this case, changing > the import path is the correct and only thing to do; you want this other, > new package, not the old one. > b) The meaning coopted by github: Creating a clone, which contains largely > the same code and is meant to track the upstream repository. Only used, to > publish changes, so upstream can pull them (hence "pull request"). In this > case, this new package isn't really supposed to have an identity at all; > it's just a publicly hosted copy of the original for convenience. > > This second case, is what people often are concerned with, when they > complain about this issue. But it seems very reasonable to me, that this > notion of fork does *not* support go-getting in the same way. After all, > it's not a package to be distributed, it only exists, so that upstream can > pull the changes to check them. And upstream can still do that, for example: > > $ cd $GOPATH/src/github.com/upstream/package > $ git remote add fork g...@github.com/fork/package > $ git fetch fork > $ git checkout fork/master > $ go test ./... > > So, the gist is: If you are doing the second kind of fork, you can't use > go-get, but that's a good thing; it's not a distributable package. If you > are doing the first kind of fork, you have to change the import paths to > the new identity, but that's a good thing: You are clearly saying, which of > the two, now distinct packages, you need. > > > On Thu, Nov 16, 2017 at 9:10 AM, Ally Dale <vip...@gmail.com <javascript:> > > wrote: > >> Hi all, >> I was confused that why golang do not support referencing local package. >> eg: import "./local2" //error: local import "./local2" in non-local >> package >> I have upload a test project here: >> https://github.com/vipally/localpackage >> >> Here is my trouble: >> My project path is: github.com/vipally/localpackage The local package >> reference relation is: main <- local2 <- local1 In "main.go" use such to >> reference local package local2: import " >> github.com/VIPALLY/localpackage/local2" Someone who forked this projcet >> as "github.com/someone/localpackage". But how can his project working by >> avoid following change? import "github.com/SOMEONE/localpackage/local2" >> >> Here maybe one solution: >> 1. use package comment to specify root of local project in projcetroot >> package main // import "#" >> 2. use someway to reference local package >> import "#/local2" >> >> REFERENCE: https://github.com/vipally/localpackage >> >> Thanks for reading! >> Ally >> >> -- >> 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 <javascript:>. >> 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.
