Closed njgheorghita closed 5 years ago
Hrm, is this just meant to be demonstrative or are you thinking this would be core functionality?
If the later, then I'm going to push back against using click
. Reasoning:
ethpm
is supposed to be a library, aka, building block for many other tools to build onclick
.ethpm
requires a specific click version range, then that second layer library is constrained to use that same version range.If we do package CLI functionality which I'm somewhat skeptical about, we should use argparse
since it is standard library.
@pipermerriam Not yet sold on it either. More demonstrative than core functionality. It was an experiment to attack the simplest case of packaging up contracts - but it gets pretty complex as soon as we start adding contract types and dependencies - to the point where i'm not really sure if this approach is worth further developing.
Your point about not including click makes sense, i'll stick to argparse. I'm going to dive into creating a manifest from solc
output next, which seems like it might be a more robust solution.
Closing since a cli isn't in the plans for py-ethpm
What was wrong?
Creating a manifest for your own set of contracts is confusing.
How was it fixed?
Wrote a cli tool to guide through manifest creation process. It right now only supports the simplest case manifest (i.e.
owned
).Right now the best way to run the tool is simply
python generate_manifest.py
frompy-ethpm
root dir.Still thinking about the best way to expand it's feature set. Any feedback on the current/future state of this tool would be lovely!
Cute Animal Picture