Cosmos-sdk: proposal: cosmos-sdk-cli

[ebuchman]

A new binary, cosmos-sdk-cli, that will start by having just the cosmos-sdk-cli init command, which can be used to initialize a new sdk repository with a Gopkg. We can have flags like --bare or basecoin to determine what files we start with.

cosmos-sdk-cli could be the start of a larger toolchain for working with and verifying sdk code.

[cwgoes]

"CDK" - "Cosmos Development Kit" - cdk init?

Anyways, I like the idea generally - although I think we want to be careful to avoid re-implementing the wheel (e.g. I'm not convinced EthPM is a wise idea; better to have our libraries operate in a compatible manner with existing tooling).

[rigelrozanski]

I'm a bit confused with why we'd like to separate out init to a common binary... what's wrong with keeping the init command with gaiad, basecoind etc.? The init command is going to have specific requirements based on the sdk-application being used with it.

Was there any other intention of this binary? Are you thinking also for blockchain debugging tooling?

[ebuchman]

This is an init command for the code repo itself - it will create a Gopkg.toml and the recommended directory structure. Nothing to do with initializing an actual blockchain.

[rigelrozanski]

fantastic idea

[faddat]

This is really great.

One issue that I've had in diverging from the cosmos-sdk repo is the build system. If this "init" could "init" a repo that has the needed build setup, it would save a ton of time and help things get done more quickly.

Love this idea.

[svaishnavy]

This is a great idea. Is anyone working on this already? I've some free time this week and would like to collaborate on this one.

[ebuchman]

Go for it!

[svaishnavy]

I've implemented a tool called cosmos-zone which will create a new project (based on the democoin in cosmos-sdk examples). Try out and let me know if this was the intended purpose of the tool.

https://github.com/svaishnavy/cosmos-zone

[rigelrozanski]

looks good - obviously we want to add this functionality directly into the SDK. high level comments:

• probably shouldn't include any of the basecoin modules in the template, if anything folks could import those directly from the SDK (probably the complete ones from x/)
  
  
  
  • I'm imagining that the template should probably not be copy and pasted from a template directory but hard coded into the tool? there ultimately should be that that much code, just a high level structure.. just my OP - not certain though, might not be the worst idea to have separate template files if the template grows... but then again maybe that's a red-flag if our template grows so large that it can't be hard coded in and we want to maintain the requirements for a basic sdk app super small
  
  

[svaishnavy]

Hi @rigelrozanski Thanks for your feedback.

I agree with you on 1) - I wanted to implement a way to easily get started. So copy pasted democoin app directly into code.

1. I do not want to have a growing template for ever. I will have something called AppReader, which will read the existing Application(app/app.go) and convert them into code segments, so we can easily add new extensions to them. So in future, adding a new extension should be as simple as calling
   cosmos-zone create-extension my_new_extension
   This will do what is required to include the extension in App, add code to include the new extension in different code segments, and also create a structure for the new extension in say... project/x/new_extension.

I will also add support for adding extension from other repositories say..
cosmos-zone add-extension github.com/cosmos/cosmos-sdk/x/bank
This will add the extension bank to the App.

But to get to this level, we need a stable Cosmos-SDK and a stable way to create/register extension.

For now I think I'll keep this outside of Cosmos-SDK, and merge them when it is stable.

[svaishnavy]

Based on your feedback, I'll do three things -

1. Cut down the template to an absolute minimum required to get started.
2. Release an executable binary of the tool so that there is no confusion on where the template lives. When running a make the tool packages the template into the binary so they are not copy pasted even now.
3. Start exploring how to add new extensions easily.

[rigelrozanski]

Cool, yeah maybe holding off for sdk stability is a good idea, one less thing which needs to be maintained prelaunch - I will mention however if we merge into the SDK it get's maintained for every change - it's very easy for tools to get out of sync

[svaishnavy]

So you are saying that cosmos team will add the template with every release? Sounds good to me. The tool automatically packages whatever templates into a binary already. Then it is not much work to merge this tool into SDK. Can you point me to the guidelines of contributing to the CosmosSDK?

[rigelrozanski]

yeah your main.go would go into a new package within the sdk cmd/ directory...
here are our contributing guidelines from a high level: https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md

[svaishnavy]

Aah thank you. I missed the CONTRIBUTING.md, was going through README, but missed it. Will merge sometime in the next few days.

[svaishnavy]

I'm trying to follow the steps in CONTRIBUTING.md but looks like develop branch is very much out of sync. What branch should I check out from? master?

[rigelrozanski]

oh gosh - we did something weird by changing our work flow but not that file, yes please work from master

[svaishnavy]

Hi @rigelrozanski Thanks! I was able to add cosmos-sdk-cli to cosmos-sdk but the test_lint fails due to templates. I have ignored the cosmos-sdk-cli folder from linting. Is this fine?

You can checkout the commits here: https://github.com/svaishnavy/cosmos-sdk/commits/svaishnavy/cosmos-sdk-cli - Let me know if this is ok to be pushed to master.

Also, I'm trying to add two new build targets(build_cosmos-sdk-cli and install_cosmos-sdk-cli) in make file, but those gets ignored. Do you know why? Where should I include these new targets? (This is fixed, my apologies).

[marbar3778]

Can we close this in favor of #4191, @rigelrozanski you in favor?

[marbar3778]

Closing this issue in favor of #4191 .If you are coming to this issue after the fact, please refer to #4191 for further discussions. :)