Date
1 - 4 of 4
[Hyperledger Project TSC] [Hyperledger-fabric] [Decision needed] dealing with go import path post Gerrit migration
|
Brian Behlendorf <bbehlendorf@...>
I'm cc'ing the TSC, as I think this is
something that affects the technical efforts project-wide, and
should be decided as an HL standard (or at least intend towards
one). Follow-ups should probably be directed to the TSC list.
My preference would be for anything that reduces impediments to on-boarding new developers. My secondary preference would be to leverage github when it adds value but avoid concentrating dependency or risk upon it. For that, I think that means option 2 rather than option 1. Brian On 07/30/2016 04:37 AM, Baohua Yang wrote:
-- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf |
|
|
|
Sheehan Anderson <sheehan@...>
Option 2 follows the path that the Go team uses. Go is developed in Gerrit, mirrored in GitHub, and uses golang.org for package names. I vote option 2 also. I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, and should be decided as an HL standard (or at least intend towards one). Follow-ups should probably be directed to the TSC list. My preference would be for anything that reduces impediments to on-boarding new developers. My secondary preference would be to leverage github when it adds value but avoid concentrating dependency or risk upon it. For that, I think that means option 2 rather than option 1. Brian On 07/30/2016 04:37 AM, Baohua Yang wrote:
On Sat, Jul 30, 2016 at 1:05 AM, Christopher B Ferris <chrisfer@...> wrote:
go imports. gotools has rules that map automagically: e.g. `go get github.com/hyperledger/fabric` will automatically map `github.com/hyperledger/fabric` to `https://github.com/hyperledger/fabric.git`. With the migration to Gerrit, we have a few options: 1) leverage the mirror of the fabric (and other) repos to GH and let nature take its course 2) leverage the ability to establish a non-GH identity for our project leveraging the <meta> tage configuration supported by Go [1]. Option 1 is possibly least disruptive, but misleading and possibly confusing, as we really live in Gerrit, not GH. Option 2 actually allows us to establish our own identity. e.g. we could establish the package as hyperledger.org/fabric. We could host our generated docs at that URL, hanging off of the hyperledger.org domain and linked from say hyperledger.org/community and include the <meta> tag that informed go where the corresponding git repo resides. e.g.: <meta name="go-import" content="example.org git https://gerrit.hyperledger.org/r/p/fabric"> We just need to include this meta tag in the HTML served up from https://hyperledger.org/fabric. I believe we can do this, just need to dig a little on how we can either embed the readthedocs content (which they support) or augment the metadata they publish by modifying the template (also supported I believe). In any event, option 2 would yield the following: `go get hyperledger.org/fabric` would install the source at: `$GOPATH/src/hyperledger.org/fabric` This is a bit cleaner, and again, we have our own identity. There are some doc changes needed to reflect this, and some tweaks to the devenv setup, but personally, I prefer option 2. Maintainers, please weigh in with your thoughts and indicate your preference. Others are invited to do so as well. Of course, if there are better ideas out there, we welcome those as well. Thoughts? [1] https://golang.org/cmd/go/#hdr-Remote_import_paths Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Open Technology IBM Cloud, Open Technologies email: chrisfer@... twitter: @christo4ferris blog: https://developer.ibm.com/opentech/author/chrisfer/ phone: +1 508 667 0402 _______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric -- Best wishes! Baohua _______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric --
|
|
|
|
That causes issues of duplicated local dirs. e.g., the go tools pkg, there're two repos under GOPATH. Some time you may get one tool from github, then another one from golang. Looks weird. :( On Thu, Aug 4, 2016 at 3:29 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
--
Best wishes!
Baohua |
|
|
|
Andrew Bransford Brown <andrewbb@...>
I concur. And I understand. Double-sets of books. Understanding hidden forks. Andrew B. Brown 10723 River Plantation Drive Austin, Texas 78747 (512) 947-8282 On Wed, Aug 3, 2016 at 7:45 PM, Baohua Yang via hyperledger-tsc <hyperledger-tsc@...> wrote:
|
|
|
Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a
Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a
Brian Behlendorf via hyperledger-tsc ---08/01/2016 01:16:15 PM---I'm cc'ing the TSC, as I think this is something that affects the technical efforts project-wide, a