On Sat, Nov 18, 2017 at 12:19 PM, Ally Dale <vipa...@gmail.com> wrote:
> 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? > > Disclaimer: I'm not on the go team. This is how *I* view these problems, personally. There is none. There are no "local" packages (a better, more correct phrasing, would be that there *shouldn't be* any local packages; they are still in the spec, but discouraged). There are two packages github.com/vipally/localpackage github.com/vipally/localpackage/local Forking the repository creates two new packages (which might or might not be intended, see below): github.com/forker/localpackage github.com/forker/localpackage/local where github.com/forker/localpackage imports github.com/vipally/localpackage/local Now, my message above applies. There are several semantic intentions possible from the fork (and the github overloading of the term "forking" is, what muddies them): 1. forker intended this to be a "soft-fork", only used to publish a branch to be pulled by vipally. In that case, they intend it to be a copy of the repository github.com/vipally/localpackage, the creation of new, public Go packages is an unintended side-effect of the way go-get and github forks interact. It is WAI (and working as in every other language) that they have to manually make sure, the compiler finds it under the name github.com/vipally/localpackage; usually by adding their soft fork as a remote to the directory in $GOPATH and checking out their own branch. 2. forker intended this to be a "hard-fork" of vipally/localpackage and not a fork of vipally/localpackage/local (i.e. they want to continue to use upstream). In that case, the creation of the github.com/forker/localpackage Go package is an intended effect, the forker/localpackage/local is an unintended side-effect. It is WAI (and as in every other language) that the soft-forked subdirectory isn't used by anyone. It should be deleted, to avoid anyone accidentally using it. No import paths have to change. 3. forker intended this to be not be a fork of vipally/localpackage and a "hard-fork" of vipally/localpackage/local. In that case, creation of github.com/forker/localpackage was an uninteded side-effect, remedied by renaming forker/localpackage/local to forker/local and publishing that. It is WAI (and as in every other language), that anyone wanting to use the hard-forked new package needs to change their import paths. 4. forker intended this to be a "hard-fork" of vipally/localpackage and all its subrepositories. In that case, the creation of any new packages is not a side-effect, but an intended state. It is WAI that forker now has to change the name of the package they want to use in forker/localpackage - if nothing else, then to distinguish it from the former cases. So, the distinction with other languages comes from two things: a) Go doesn't have "subpackages". Every package has an identity completely disconnected from any other package, even though source control might choose to distribute them together. b) Go does not require you to push to a centralized package-registry to publish your package, but adds a discovery mechanism based on the import path instead. Arguably, most of the confusion comes from the fact, that Go has "magic" to allow github.com/user/repo/package to be go-get'ed (instead of requiring what today is called a "vanity import") in conjunction with github's decision to publish soft-forks implicitly under the forking username. It muddies the distinction between an intentional, hard fork and republishing of a package and a soft fork, that is supposed to just present a temporary proxy to an upstream repo. But there still isn't an actual *diference* between Go and Non-Go, here. Once you realize a) the import path is the *identifier of the package* and b) creating a go-gettable github-repository is the conceptual equivalence of publishing something to Hackage/PyPI/npm/CPAN… under that ID. You would not expect "pip install django" to fetch your django-fork and you wouldn't use "pip install django" to start hacking on it. You would clone the repository locally, tell your python interpreter where to find the code and then add your fork as a remote. *Do the same in Go*. (Note: There is a valid point in that Go makes it harder than languages with subpackages, to maintain a "hard fork" of a package, as you have to continually rebase the import path change to point to your hard fork. That is true, but 1) not usually the complaint brought forth, 2) IMO a rare enough case that it's a small price to pay for a good packaging/discovery mechanism in general and 3) I'm not even sure it's a *bad* thing. Hard forks most of the time suck for everyone involved) > 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. > > Project name, sure, that's a huge amount of work. But it's a huge amount of hard to automate work *anyway*, as usually a project name appears in more places than just an import path. Adding a trivially automated, tiny amount of work to rewrite import paths, for such a rare case, seems like an okay tradeoff to me. Changing the source control server is not harder in Go. Use your own Domain for your package paths, then simply swap out the meta-tag. Easy as pie. But also, if you are not publishing your repositories, *what does it matter*, whether they are go-gettable? > 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> >> 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. >>> 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.
