.abi.json support

[devhawk]

The Neo Compiler for .NET (aka NEON) emits a .abi.json as part of the compilation process. this file contains the function names, parameter names and types and return type of the main contract entrypoint and all public methods in the contract. By convention in .NET, the main entrypoint is a switch or series of if statement that dispatches based on the first parameter, which is usually a string.

Neo Visual DevTracker uses this file to drive the Invoke Contract UI inside of VS Code

If neo-boa could emit an abi.json file or something similar, Neo Visual DevTracker can provide a better developer experience for invoking that neo-boa contracts inside of VSCode

[ixje]

Some Discord history on the topic;

• devhawk pointed out; C# contracts use assembly attributes for contract meta data example
• devhawk pointed out; for C# contracts the function/methods included in abi.json are those that are public.
• Python doesn't have the hard concept of public/private functions as such I said the following about how this might be done for Python

  The fastest way is to tell python contract users to create an abi.json in which they have to describe the public functions with types in order to get debugging assistance. We could provide a template of which they can build. The alternative idea of creating a function decorator requires significantly more work with little reduction in what data they have to enter (at least until point 6 (typing) is supported)

Moving forward Note that the goal is to require the least amount of input from devs.

1. I see the manual abi.json approach (based of a template) as a viable short term solution to get some form of support of the ground. Part of the reasoning is that the amount of public functions is expected to be limited, so it's a limited one off exercise.
2. Long term would be supporting PEP484 and its companions in smart contracts.
3. Using 2. we can reduce the required manual input to a list of public function names. Types and params can be extracted.
4. A @public decorator could mark which functions to include in the abi.json minimizing the last burden of 3.. This relies on being able to differentiate a decorator function from regular functions in the AST (which I don't know if we can).

I believe the neo-visual-devtracker team is most suited to pull 1.. The output is a direct input to their tool. By pulling it we cut out any iterations on what format it should be as integration is happening.

@devhawk

[devhawk]

@djnicholson (primary dev on devtracker)

devtracker uses the abi.json file for two things: Contract Metadata during deployment and to drive the contract invocation UI.

For contract metadata, I think we already have support in devtracker to prompt the user in cases where the abi.json file doesn't include contract metadata (it was a recent addition to NEON). I figure this could be expanded to support the case where the abi.json file is missing entirely.

for contract invocation, the DevTracker could be updated to get the main entrypoint parameter list from avmdbgnfo file if the abi.json is not available. That would not be as good an experience as the C# developer gets, but it's a start.

furthermore on contract invocation, I think we might have a better solution than manually generating and abi.json file. as a command line tool, Neo-express has limited ability to express contract invocation parameters. I've been talking to @djnicholson about using the devtracker invoke contract UI to collect the parameters for a given contract invocation and save them to a json file that neo-express could use. Maybe we could use that same infrastructure (when we build it) to allow python developers to specify the names + parameters for their contract's operations. That would be a better experience than hand-authoring an abi.json file.

[ixje]

Fixed in v0.7.0