denyeart
commented
5 months ago The utility code is internal because it is not designed to be used by other consumers. Fabric repository is versioned as a set of executable binaries rather than a typical Go module that is intended to be consumed. If you build an application that depends on internal Fabric code you may experience unexpected breaking changes as Fabric evolves.
Concerning configtxgen, for programatic update of channel configuration, the intent was to utilize the library in https://github.com/hyperledger/fabric-config, and then have a set of client applications that imported the fabric-config module. Although the fabric-config library was completed, the project has not yet utilized fabric-config in other client applications, although that is still the intent for https://github.com/hyperledger/fabric-admin-sdk. You are welcome to build your own client applications around fabric-config as an alternative to the yaml-based configtxgen. Alternatively, you could collaborate on https://github.com/hyperledger/fabric-admin-sdk. Regardless, I would suggest to first look into fabric-config to see if it has libraries that you are interested in.
Cryptogen is a different story, it is intended to be a lightweight utility to generate certificates for test environments. It is not intended to be used in production networks, is limited in function, is not expected to be enhanced, and may change at any time. In a nutshell, not something I'd recommend depending on.
Current Status
Both cryptogen and configtxgen import internal go modules. Meanwhile cmd/cryptogen and cmd/configtxgen seem tightly-encoupled to using yaml files. Using yaml files would result in decreased maintainability as the app scales up. As there are some bits and pieces of the code in e.g., internal/cryptogen/ca, csp, msp, etc. that are useful for generating certificates, it would be nice to know the reasoning behind them being internal modules, or else would be nice to have them available publicly, such that we developers can make use of those functionalities more dynamically, without being constraint to either generating a yaml for the sake of generating crypto materials, or porting over the internal code to the project.
Expected
Both cryptogen and configtxgen are capable of importing non-internal go modules available to public.
Solution
Both cryptogen and configtxgen are capable of importing non-internal go modules available to public.
Please let us know if you plan to work on this.
If the devs don't have specific time to make this refactoring change, I would love to if you would like me to contribute.