Thanks for replying all above. The main point of this topic is probably to discuss "what's the right way to manage local-only packages". 1. Axel has point out that "why local-packages is not necessary in golang" 2. Jake has given an effective way to use "vendor" path to fix local-refering problem. But this is with a liitle defective that it's depart from vendor's original goal--manage explicit-version of third-party packages. 3. Goalng has a local package refer solution with "./xxx" "../xxx" style. But this is not recommeded by go team. a)It may cause out-of-control problems(“../.../xxx” maybe refer to a path out of my project). b)It doesn't work when working path is under GoPath(error: local import "./local2" in non-local package) . c)local and global package reference style cannot working well together. 4. "#/xxx" style reference seems a best solution like "vendor" to fix local-package reference problem. Without any hard code "where I am" exists in any go files. And it will works well together with current global-style, because "#" will be replaced with <ProjectRoot> by compiler automatically.
在 2017年11月18日星期六 UTC+8下午7:19:33，Ally Dale写道： > > > 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. > > > >> -- 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.
