Ethereum Python Roadmap - Part 2
ethereum·@pipermerriam·
0.000 HBDEthereum Python Roadmap - Part 2
<html> <p>A month ago I posted some information on the python ecosystem for Ethereum development. You can read that post <a href="https://www.reddit.com/r/ethereum/comments/4polro/python_tooling_roadmap/">here on the /r/ethereum subreddit</a>.</p> <p>Since then a lot has happened so I believe it is time for an update.</p> <p><br></p> <h2>Ethereum TestRPC and Tester Client</h2> <ul> <li><a href="https://github.com/pipermerriam/eth-testrpc/">https://github.com/pipermerriam/eth-testrpc/</a></li> <li><a href="https://pypi.python.org/pypi/eth-testrpc">https://pypi.python.org/pypi/eth-testrpc</a></li> <li><a href="https://github.com/pipermerriam/ethereum-tester-client">https://github.com/pipermerriam/ethereum-tester-client</a></li> <li><a href="https://pypi.python.org/pypi/ethereum-tester-client">https://pypi.python.org/pypi/ethereum-tester-client</a></li> </ul> <p>These two libraries are both abstractions on top of the <code>ethereum.tester</code> EVM from the <code>pyethereum</code> repository. </p> <p>If you would like to interact with the test EVM directly from your python code I recommend using the <code>ethereum-tester-client</code> library. It implements the vast majority of the APIs that geth exposes over its various interfaces.</p> <p>If you need to test RPC interactions then I suggest using <code>eth-testrpc</code> which implements the vast majority of the JSON-RPC inferface that is exposed by <code>geth</code>. Under the hood, it is merely a layer on top of the <code>ethereum-tester-client</code> library.</p> <p>Both libraries support python 2.7, 3.4, and 3.5.</p> <h2>Web3.py</h2> <ul> <li><a href="https://github.com/pipermerriam/web3.py">https://github.com/pipermerriam/web3.py</a></li> <li><a href="https://pypi.python.org/pypi/web3">https://pypi.python.org/pypi/web3</a></li> </ul> <p>The <code>web3.py</code> codebase is now ready for public consumption. The entire codebase has been overhauled, adding significant test coverage, and expanding the library to implement very close to 100% of the functionality that users of the Javascript Web3.js library are familiar with.</p> <p>The one exception to this is the contract interface which I chose to implement according to the <a href="https://github.com/ethereum/EIPs/issues/68">EIP68 specification</a>. I believe that this specification provides a much cleaner manner of interacting with contracts and makes it much clearer to users whether they are sending a transaction or just calling a contract function.</p> <p>This library supports python 2.7, 3.4, and 3.5.</p> <p>One of my favorite parts of the library is the <code>TestRPCProvider</code>. This provider automatically spins up the <code>eth-testrpc</code> server for you so that you can test your <code>web3.py</code> code against an in memory EVM. This provides lightning fast tests with a high guarantee that any code you write will also work when interacting directly with the <code>geth</code> backed JSON-RPC server.</p> <h2>py-geth and py-solc</h2> <ul> <li><a href="https://github.com/pipermerriam/py-geth">https://github.com/pipermerriam/py-geth</a></li> <li><a href="https://pypi.python.org/pypi/py-geth">https://pypi.python.org/pypi/py-geth</a></li> <li><a href="https://github.com/pipermerriam/py-solc">https://github.com/pipermerriam/py-solc</a></li> <li><a href="https://pypi.python.org/pypi/py-solc">https://pypi.python.org/pypi/py-solc</a></li> </ul> <p>Both of these libraries provide python wrappers around the underlying executables.</p> <p><code>py-solc</code> provides the high level <code>compile_files</code> and <code>compile_sources</code> functions for Solidity compilation from within your python code. It also provides a <code>link_code</code> function to handle library linking. If you would like to do lower level things you can also dig into the code and should be able to find access to whatever parts of the underlying <code>solc</code> api that you need to access via the <code>solc.wrapper.solc_wrapper</code> function.</p> <p>In the same vein, <code>py-geth</code> provides high level tools for running the go-ethereum <code>geth</code> client from your python code. It provides the classes <code>LiveGethProcess</code> and <code>TestnetGethProcess</code> that are pre-configured to run the main and morden networks respectively as well as the <code>DevGethProcess</code> which is intended for running local private blockchains for things like testing.</p> <p>All of these classes have the following friendly APIs.</p> <ul> <li><code>GethProcess.accounts</code> returns the list of account addresses</li> <li><code>GethProcess.data_dir</code> returns the path to the underlying data directory for the geth process.</li> <li><code>GethProcess.rpc_enabled/rpc_port/rpc_host</code> for information about the JSON-RPC interface.</li> <li><code>GethProcess.is_rpc_ready</code> which returns whether the JSON-RPC server is up and listening.</li> <li><code>GethProcess.wait_for_rpc(timeout=0)</code> which blocks for up to <code>timeout</code> seconds waiting for the JSON-RPC server to come online.</li> <li><code>GethProcess.ipc_*/is_ipc_ready/wait_for_ipc(timeout=0)</code> for identical functionality to the corresponding <code>rpc</code> methods and properties.</li> </ul> <p>The <code>py-geth</code> library also provides a few mixin classes that can be used to do things like writing all of the geth output to stdout/stderr, or piping it into a logger via the <code>geth.mixins</code> module. Examples available in the project readme.</p> <p>Both libraries supports python 2.7, 3.4, and 3.5.</p> <h2>Populus</h2> <p>All of the above libraries were precursors to the main work I've been wanting to do. Populus is currently in a beta release cycle for a 1.0 stable release. </p> <p>Part of this release involved trying to establish a baseline for stability in the library so that some of the more advanced features I've been dreaming up are possible. This meant removing two major commands, <code>populus web</code> and <code>populus attach</code>. These command respectively ran a webserver and spun up a python console. They were both poorly supported, sloppily implemented, and very fragile.</p> <p>In addition, there were large parts of the populus codebase that would be better served as standalone python packages. The <code>py-solc</code> and <code>py-geth</code> libraries both removed large pieces of complex subprocess based logic. The work on <code>web3.py</code> has allowed removal of very large portions of code from the codebase while simultaneously making the blockchain interactions much more robust and reliable.</p> <p>All in all these refactors and repackaging allowed me to remove 13,000 lines of code, tests, and fixtures from the populus codebase.</p> <p>The optimist in me is hoping to get 1.0 released this week. The realist in me thinks it's more likely to be another week away. I'm working hard on <a href="https://github.com/pipermerriam/populus/pull/113"><code>populus migrate</code></a> which was conceptually inspired by <code>truffle migrate</code>. Anyone who is familiar with Django migrations should immediately recognize the architectural similarity. The goal is to provide a framework to automate complex deployments as well as setting the stage for a full packaging and releasing system.</p> <p>Populus supports python 2.7, 3.4, and 3.5.</p> <h2>Deprecation</h2> <p>Part of this process has been deciding to deprecate some of the libraries that were initially part of this refactor but became obsolete. <code>ethereum-rpc-client</code>, <code>ethereum-ipc-client</code>, and <code>ethereum-contract</code> will no longer be supported. The role they once filled has been replaced by better things in other libraries.</p> <p>I hope you'll join me in continuing to advance the python toolchain for the Etherum ecosystem. Happy Hacking!</p> </html>