Go get version is still old with v2.1.1+incompatible

[yeasy]

Reproduce

go list -m -mod=mod -versions github.com/hyperledger/fabric

github.com/hyperledger/fabric v0.6.0-preview v0.6.1-preview v1.0.0-alpha v1.0.0-alpha2 v1.0.0-beta v1.0.0-preview v1.0.0-rc1 v1.0.0 v1.0.1 v1.0.2 v1.0.3 v1.0.4 v1.0.5 v1.0.6 v1.1.0-alpha v1.1.0-preview v1.1.0-rc1 v1.1.0 v1.1.1 v1.2.0-rc1 v1.2.0 v1.2.1 v1.3.0-rc1 v1.3.0 v1.4.0-rc1 v1.4.0-rc2 v1.4.0 v1.4.1-rc1 v1.4.1 v1.4.2 v1.4.3 v1.4.4 v1.4.5 v1.4.6 v1.4.7 v1.4.8 v1.4.9 v1.4.10 v1.4.11 v1.4.12 v2.0.0-alpha+incompatible v2.0.0-beta+incompatible v2.0.0+incompatible v2.0.1+incompatible v2.1.0+incompatible v2.1.1+incompatible

Solution

Update the fabric releases to the public Go module repository.

[denyeart]

@yeasy What exactly is your proposal here?
We had previously decided not to update Fabric module to /v2, since Fabric is not a dependency that other Go projects should pull in with "go get", and we don't want to give that impression.
v2.1.1+incompatible is displayed because it was the last release prior to converting the project to go modules.

[yeasy]

First, as an open source project, it's not appropriate to "decide" the users' usage method.
I get the point that fabric is not a pure dependency, but it's possible that the users want to take whole or part of its code.
On the other way, supporting go get does not mean it's an dependency, as most go projects do today. It is just a native way to obtain some golang based project.
Hence it will be more friendly to keep enabling the go get way, instead of freezing at 2.1.1.

[denyeart]

The maintainers can certainly re-evaluate. It will require a specific proposal however. What changes would you like to contribute, what actions need to be taken, and what are the implications?

[yeasy]

// What changes would you like to contribute
If need, I can help enable the new version. It's not difficult, but I believe that requires some privilege.

// what actions need to be taken,
Update the newer fabric releases to the public Go module repository.

// and what are the implications?
Several potential implications:

• users can get confused as thinking the hlf only has 2.1.1 release from the Go repo history;
• users cannot get the newer version using go get, etc.

[denyeart]

Let me further explain the rationale of why the maintainers decided not to version the fabric go module:

• Fabric codebase pre-dates go modules and therefore doesn't follow typical module project structure and assumptions.
• Fabric repository is for the Fabric application runtime binaries and does not maintain and expose a public API. The fabric public API is in the various fabric-protos repositories that fabric repository pulls in and consumers can pull in.
• There are functions exported for internal use within the repository that consumers may misinterpret as public APIs if it were published as a versioned module.
• Since Fabric repository is for application runtime binaries, it uses semantic versioning based on runtime behavior rather than on internal API compatibility. However, module versioning requires semantic versioning based on API compatibility.
• Go reference documentation around module versioning is all about consumers importing code. However, Fabric discourages consumers to import core fabric repository code, if they do it will change and break them in unexpected ways.

The maintainers concluded the above considerations outweighed the ability for users to go get fabric code.

So far, the proposal here does not bring any new information for maintainers to consider. Again, the maintainers could re-evaluate, but it would require a more detailed proposal that addresses the concerns and implications above. Considering the fundamental differences between an application binary repository and an importable repository, I would expect any such proposal would require significant code refactoring to get it aligned with expected Go module practices, and as such would likely require an RFC rather than a github issue, which you are welcome to open.

[alfredomusumeci]

Hello, in regards to this, I have cloned the fabric branch 2.5.0 to use it as a local package. However, there seems to be a problem related to one of the package which would require using fabric go package to solve. More specifically, if I have any custom pluggable Validation that imports protoutil and I try to use the Identity package I get the following:

package command-line-arguments
	imports github.com/alfredom/fabric/protoutil
	vendor/github.com/alfredom/fabric/protoutil/commonutils.go:17:2: use of internal package github.com/hyperledger/fabric/internal/pkg/identity not allowed

This is because identity is under the folder internal, and therefore it acts like a private folder. I then tried to import fabric v.2.1.1+ incompatible using go get, and the problem seems to go away. HOWEVER, at compilation time then I get many different kind of errors all relating to protobuffer, which I suspect is somewhat connected to protoutil.

Hence: either 2.1.1 needs to be upgraded to 2.5 or the identity package needs to be taken out of the internal folder and put somewhere else so that it doesn't cause this error.
More about this at: #4200

Looking forward to you answering

[bestbeforetoday]

I think the previous comment mentioned pretty clearly that the hyperledger/fabric module does not provide a stable public API and is not intended to be consumed as a dependency by other modules. It sounds to me like you are trying to do something that is not intended to work and is not supported. What are you actually trying to achieve?

[alfredomusumeci]

I am trying to add a custom validation plugin, really, and in order to do this I have no choice but to import hyperledger/fabric. If I were to use the google dependency I get all sort of errors, ie the one mentioned above. So, I believe my only option here is forking the repository and making all local changes I need and then importing it as a local copy altogether. Thanks for your comment though.

[bestbeforetoday]

Certainly not something I have tried but thank you for clarifying what you're trying to do. It is definitely helpful in case others can offer suggestions.

I notice this post on the Fabric mailing list that might be helpful. I suspect that you are correct and either forking the Fabric codebase or just copying the bits of code you need to implement your plugin will be the best approach. Maybe somebody else has better information.