New bootstrap structure prevents easily building go code locally #23
Comments
|
I'm not sure what the problem is here but it would probably be useful to include a reference to how to set up Go for chaincode development, e.g. https://golang.org/doc/code.html. in the chaincode bootstrap documentation. See IBM-Blockchain-Starter-Kit/IBM-Blockchain-Starter-Kit.github.io#13 Leaving this issue open for now in case there are any specific changes that could be made to the project structure that would help. |
|
To build the Go chaincode locally, the bootstrap project should be under the (Presumably fabric would need to be in the workspace as well?) Having said that, it probably makes more sense to follow the approach described in the fabric tutorial using the fabric samples where the chaincode is actually compiled inside a development chaincode container. Unless there's a really good reason not to, we should strive to keep the starter kit aligned with the fabric samples and tutorials. |
|
https://github.com/IBM-Blockchain-Archive/learn-chaincode has a bit in the readme about setting things up to compile locally |
|
Hello @jt-nti, here's a summary of my findings. The chaincode component examples I have seen online are very simple and compile just fine, even when there is no The above works just fine, no hiccups. However, let's look at a folder structure that is closer to what you will find in the real world when developing chaincode: The above fails; it cannot find a local package ( The good news is that Go already has a mechanism that allows you to compile your code no matter where you have it in your local file system. To compile the chaincode shown above, you'd need to do the following: 1) Your The above now compiles just fine now that I have a Also, as a side note, I'd say that having to spawn a container for compiling and testing chaincode introduces more work for the developer. As a developer, I would prefer to compile and test my code as quickly as possible with as little overhead as possible on my local platform. |
|
Hi @rolivieri, thanks for the summary. I've not seen that GOPATH trick before- it doesn't seem to be a recommended approach in the Go documentation that I've found Given these projects are meant to define best practices, my gut feeling is that it would be better to steer people towards the standard Go setup, which does seem to be much more prescriptive about structure. Having said that, if there are strong views that including the On the subject of spawning a chaincode container- that would be overkill for simple compilation but it does seem like a good way to test and debug chaincode in a real fabric environment locally. |
|
Hello @jt-nti, yes, adding multiple folders to the My point is not so much about the
If there is a way that we can achieve the above and does not require having the Let's say we do not have a How can we have the developer compiling and running the test cases as quickly and as seamless as possible? If there are other mechanisms, sure, let's discuss them. |
|
@rolivieri @jt-nti no open source projects written in Go check in a
The This is documented in the Go documentation here: https://golang.org/doc/code.html
Putting the |
|
@jt-nti @sstone1 Guys, let's put aside the solution I shared about
Can you suggest ideas on how to achieve this (besides symbolic links)? What other options are there to make the developer experience as seamless as possible? For instance, say a developer clones from GitHub a chaincode repository to his/her local file system with the following folder structure: How can we have the developer compiling each chaincode component (note that a chaincode component may have local modules as depicted above) and running their test cases as quickly and as seamless as possible? Any suggestions, thoughts? I am looking for ideas on how to solve this problem. |
|
@rolivieri see previous answer 😉
Go chaincode developers have to do exactly the same thing for chaincode that they do for any Go code they work on; set up a Go development environment and put it into a Go workspace as defined by the GOPATH environment variable. If they don't like that, then perhaps they should pick another programming language for their chaincode with less restrictive rules around file system layout and structure.
As long as they check their Go chaincode projects into a Go workspace, then all the appropriate Go commands ( |
|
@jt-nti I have removed the @sstone1 Thanks for moving the conversation forward. This is mainly what I wanted to discuss with folks more fluent in Go than me and not so much the @jt-nti Given the point discussed above with @sstone1, I have a few thoughts to discuss with you about structure in the @jt-nti Can you confirm that this is your understanding too? |
|
@rolivieri that chaincode structure matches the fabric samples, and a couple of othe projects I've seen, so it makes sense to me. |
|
@jt-nti Thanks for confirming your understanding of the intent for this repo as described above. I will share some additional thoughts and considerations that I think we should have given this understanding. However, before doing so, can you point me here (or on slack) to the GO chaincode projects that you refer to in your comment above? My guess is that neither of those projects are using local submodules but I would like to take a look at then so we can both have the same reference point. Thanks. |
|
@jt-nti Let's then use the Let's first summarize the points we have agreed on:
Given the above assumptions, let's say I fork the Before I continue with the description of the issue I'd like to bring up, are we so far on the same page? Anything you see above that differs from your understanding or vision for this repo? |
|
@rolivieri I'm new to Go but that sounds like what I was expecting. I've made a start on https://github.com/jt-nti/fabric-devenv to try out some Go chaincode and I think the structure you describe works with the dev setup from https://hyperledger-fabric.readthedocs.io/en/release-1.1/chaincode4ade.html |
|
@jt-nti Thanks for confirming we are on the same page so far. Let's then expand on the sample above. Say that within one of the chaincode components listed above, we have quite a bit of code and the developer has created sub-folders inside the chaincode component folder to organize better the structure of his/her chaincode component. For instance, say that For the go files in the Now, say you navigate to the I have a suggestion to address this issue, which would require a few changes... but before getting into that, I'd prefer to pause here and make sure we are still on the same page so far. Do we agree that there is an issue or do you have a different view? |
|
I'm not sure I follow what the problem is. If the chaincode compiles locally, then it should be ok when deployed to fabric. I checked with the local Go guru and he didn't think it would be a problem. There is a potential problem with folders when deploying to IBP at the moment though, which could do with fixing. That's covered in another issue IBM-Blockchain-Starter-Kit/build-lib#67 - is that the issue you were thinking of, or is there another problem as well? |
|
@jt-nti Hello, we created the following repo so we can use it as reference: https://github.com/vandangogna/my-forked-chaincode-bootstrap (this repo is a fork of https://github.com/IBM-Blockchain-Starter-Kit/chaincode-bootstrap). In this repo, you will find two branches: Under the As I mentioned above, I have a suggestion to address this issue, but before doing so, do we concur that there is an issue? You can clone the repo and see what happens when you try to compile and deploy the chaincode components in both branches. |
|
Just documenting the latest that has been discussed:
References: |
Closing #19 introduces this problem.
The text was updated successfully, but these errors were encountered: