Manifest Builder....

[pipermerriam]

What was wrong?

I'm a bit in love with the "builder" concept so take this with a grain of salt. It may not be a good idea.

How can it be fixed?

Tools for functional compisition based manifest building.

manifest = build_manifest(
    setup_manifest(),  # stubs out some initial data to seed the manifest.
    set_meta(author=...),  # injects the `meta` information into the manifest.
    set_meta(license=...),
    set_contract_types(
        ERC20Token=extract_contract_type('ERC20Token', solc_compiler_output),
        owned=extract_contract_type('owned', solc_compiler_output),
    ),
    set_deployments(
        ...
    ),
    prettify(),
)

Rather than try to build something that is infinitely flexible, build a lot of small tools that are designed to be chained together to build a manifest... We could pair on this.

[pipermerriam]

ping @carver for general thoughts on this idea/concept.

[njgheorghita]

I like it. Seems to me like a functional approach is well-suited for this task. And this approach seems like it breaks down the (somewhat complex) building process intuitively - (rather than one generate_manifest() function that takes a wide assortment of args. I'm planning on heading up to Boulder wednesday if you want to do some pairing then to kick it off

[carver]

ping @carver for general thoughts on this idea/concept.

It doesn't stand out as bad but I'm not sure it's as great as the chain builder. The key difference to me is that the order of application in the chain builder has meaning. Mining a new block builds on the last block. Here, it looks like you could reverse all of the manifest steps, and there would be no difference in the outcome. It seems just as meaningful, and maybe simpler, to do something like kwargs, a dict, or a namedtuple, like:

build_manifest(
  meta={'author': ..., 'license': ...},
  contract_types={
    'ERC20Token': extract_contract_type(...),
  ...

(of course, internally, it can/should be split into sub-methods, and maybe even piped through, it's just not obvious to me that exposing the ordering of attribute application has any value to the user)

[cbdotguru]

Had a question for this when building in the other repo. Should this functionality be explicitly coded into the ethpm tool or should the consumer build it? I ask because the user (such as truffle) needs to map their data to the manifest keys in some way anyway. If that work has to be done on their side (because there is no way for us to know what information goes to what key unless told explicitly), then wouldn't this tool simply just need to receive a a json with appropriate keys? This would only leave the necessity to properly format, save somewhere, and post to a registry.

[njgheorghita]

@Hackdom I wouldn't consider this a core component of ethpm, just a (hopefully) useful tool for the python world where our dev framework populus is in temporary limbo. This is meant to make it easy for users (in this case developers not frameworks) to produce a simple manifest from solc standard-json output and some configuration args.

[cbdotguru]

ok ok, makes sense. Yeah, so I was thinking of doing something similar such as a cli app that can read from some common framework setups (maybe even the standard-json like yours) and putting it in the command directory to either use directly or serve as an example of how to integrate the core lib.

[njgheorghita]

Closing since this is a thing now