Proposal: Use nameservice as module scaffold

[jtremback]

Personally, I found the module that gets created as a scaffold hard to deal with, due to the fact that it does not run or even compile. Sometimes it's nice to be able to start from working code and tweak it, especially for beginners.

For this reason, I propose that the module created by the nameservice tutorial be used as a scaffold in this tool. It's not any harder to modify into your own module than the scaffold that is created now, and it runs right out of the box. @jackzampolin I think we talked about this on Twitter.

[jtremback]

I can go ahead and do this and submit a PR if it will be accepted

[okwme]

We actually had a command to build the nameservice chain with the scaffold. We removed it because it seemed less useful than a boilerplate app, and it required that the nameservice code be repeated in two places (as template and as code). The app created with the simple app command should compile actually. rather than rebuild the nameservice template i'd suggest making the scaffold tool clone the nameservice app, make it rather a shortcut to using git, maybe with the added feature of removing the original .git file? This could be expanded to other popular apps as starting points, or even allow a custom git url so it just becomes a simple wrapper for `git clone` + `rm -r .git`. What do you think?

…

On Sat, Jun 20, 2020 at 10:41 PM Jehan ***@***.***> wrote: I can go ahead and do this and submit a PR if it will be accepted — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLLVA3KN6C3NJI2RKPKO3RXUNHVANCNFSM4ODRDPNQ> .

-- billyrennekamp.com

[tac0turtle]

Personally, I found the module that gets created as a scaffold hard to deal with, due to the fact that it does not run or even compile. Sometimes it's nice to be able to start from working code and tweak it, especially for beginners.

My reasoning for this approach was to provide a way to guide the user with what needs to be done, but this may have been the wrong thinking.

What if we implement the functions so it would compile but every function has a panic("not implemented") in it. This would follow convection with other tools like impl (https://github.com/josharian/impl).

[jtremback]

@okwme I don't really like the nameservice app, since for me (and I'm guessing many developers), what is wanted is to put your own custom logic into a full-fledged clone of the Cosmos hub. The nameservice app from the tutorial only has the modules that interact with the nameservice module.

For this reason, what I would personally prefer is a command that puts the nameservice module into the lvl-max app scaffold. Having it as a Git link or whatever as you suggest is probably best.

@marbar3778 I agree that putting panic("not implemented") would be more correct than the non-compiling code that is created now, and might be better than the nameservice module for experienced Cosmos developers, who don't want to delete all the nameservice stuff every time they start a module. Maybe it would be best to have both nameservice, and a non-running scaffold module as options.

[okwme]

This brings up a larger question which came up in a conversation with Justin from Althea the other day, about what is the best way to be extending pre-existing modules. We were discussing it with regard to peggy, where althea is using the module for specifically batch transfers of fungible tokens. Peggy should be easy to extend so that it can be used as a general purpose oracle as well as transferring non-fungible tokens. This same problem came up with building the NFT module. There should be a base universal functionality, but actually each implementation will want to have slightly different logic on who can transfer and when. The solution in the NFT situation was to overwrite the handler function of the otherwise unchanged module. This allowed custom logic on handling the messages. This might not be the best solution for more complex extensions of modules though. One choice is a bit how I think you're describing, Jehan, where you just import a copy of the module in question and then you start tweaking it. The problem here is that if the work you do is more of an extension of the original than a new module, it might be the case that extension should be something like a new source as well. Like the openzeppelin NFT extensions, you can just import the different classes of NFT you'd like to use, and then overwrite the parts you want completely custom. The extensions become common sources to prevent re-writing basic (but optional) behavior. We should think about architecturally what is the best way to make extendable modules and then make the module support this developer story.

…

On Mon, Jun 22, 2020 at 4:10 AM Jehan ***@***.***> wrote: @okwme <https://github.com/okwme> I don't really like the nameservice app, since for me (and I'm guessing many developers), what is wanted is to put your own custom logic into a full-fledged clone of the Cosmos hub. The nameservice app from the tutorial only has the modules that interact with the nameservice module. For this reason, what I would personally prefer is a command that puts the nameservice module into the lvl-max app scaffold. Having it as a Git link or whatever as you suggest is probably best. @marbar3778 <https://github.com/marbar3778> I agree that putting panic("not implemented") would be more correct than the non-compiling code that is created now, and might be better than the nameservice module for experienced Cosmos developers, who don't want to delete all the nameservice stuff every time they start a module. Maybe it would be best to have both nameservice, and a non-running scaffold module as options. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLLVAUGQMY2OF2OTTOY7DRX24QZANCNFSM4ODRDPNQ> .

-- billyrennekamp.com