Hi, Here are two examples of "hello world" main packages: <ProjectRoot>/withoutlocal <ProjectRoot>/withlocal <- github.com/vipally/localpackage/local
"withoutlocal" works well anywhere <ProjectRoot> is, even out of GoPath. "withlocal" works only when "<ProjectRoot> = <GoPath>/github.com/vipally/localpackage" How does go team think about this difference? It makes "withlocal" packages non-independent due to reference "LOCAL" packages as "GLOBAL" style. If I want my package works well anywhere, I have to write all code into one "LARGE-package". Just like: all.Printf/all.OpenFile/all.GOROOT Does this go team recommended? We must explicit followed priorty of go package find process: <ProjectRoot>: with highest-priorty path to find local packages. <Vendor> : with second-priorty path to find explicit-version of local-referenced third-party packages. <GoRoot> : with third-priorty path to find standard packages. <GoPath> : with lowest-priorty path to find third-party packages. Think about that not every go-project is wrote for open-souce(aim to share with others). Thousands of private go-projects(eg:gameservers) focus their own particular logic-flow only and never shared private-packages. We just called these projects "independent-projects". Because they have hundreds-of private-packages but no one is wrote for share. That is to say, they never care "where I am", but "what I need". Unfortunately, these kind of projects are always "huge". Maybe millions-of lines or thousands-of private-packages reference inside? In this case, change project name or source control server become heavy work, because the working path changes and thousands-of private-packages reference code have to be update. But if local-packages are referenced by "#/modules/module1" style, everything is change the name of project root only then. How do you think about the difference between such styles of referencing local-packages then? "#/modules/module1" "<GoRoot>/server/user/project/modules/module1" Details: https://github.com/vipally/localpackage#examples-of-withwithout-local-package-reference 在 2017年11月17日星期五 UTC+8下午3:31:31，Axel Wagner写道： > > What kind of confuses me around these discussions is, that there are > rarely complains about having to do the same thing with, say, python > libraries. If I press "fork" on a python library on github, people can't > just "pip install" it and get crackin'. They have to manually clone it and > put it in the correct spot to be found by the interpreter, or I have to > choose a new name for it and upload it to PyPI, so people can find it. > > Well, same difference, just that a) in Go, the name/identity of a package > is conventionally scoped via a domain name, so that we don't need to give a > central authority the power over all our package names, to avoid conflicts > and b) this enables a cute, additional mechanism for discovering the > code-location, downloading it and storing it in the right place for the > compiler to discover it. But these are *extras*. Go isn't really doing > anything special or weird or different from anyone else, except that it > added a couple of conventions on top of it, to make it *more convenient* > than in other languages to distribute packages. > > Stop thinking of Go import paths as some weird and strange concept > screwing up your life. It's just a name. And the whole purpose of a name is > to identify; so if you change the identity, change the name too and if you > don't want to change the name, don't be surprised that you can't just coopt > some other packages identity. > > On Fri, Nov 17, 2017 at 7:54 AM, Volker Dobler <dr.volke...@gmail.com > <javascript:>> wrote: > >> On Friday, 17 November 2017 02:43:48 UTC+1, Ally Dale wrote: >>> >>> [...] >>> 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". >>> >> >> That's true and still the case. >> >> The "Where I am?" arises for go get where it is an obvious requirement. >> >> For go build et al. a certain notion of "where is the stuff" on the >> filesystem >> is still needed and unarguable reasonable. >> >> That different projects (and a github-style fork _is_ a different project) >> might or even should have different notions of "Where I am" was explained >> very well by Axel. >> >> V. >> >> -- >> 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.
