Populus 1.0.0 refactor changes. Request for Feedback

[pipermerriam]

Introduction

I am currently working on a major revamp of the populus library. Below is a list that I will continue to update as my work progresses. I'm very interested in any feedback on these changes as many of them are going to be breaking changes.

This refactor will also mark the beginning of the 1.x.x line of releases. After this, any breaking changes to public API's will go through a deprecation process (to be determined).

Changes

• Remove populus web command.
• Switch to py-solc package for solidity compilation
• Switch to py-geth for running geth nodes.
• Switch to web3.py for all blockchain interactions.
• Remove filtering from populus compile command.
• populus compile command now runs with --optimize enabled by default.
• Deprecate <project-dir>/libraries directory in favor of all source files being located in a single <project-dir>/contracts directory.

Details and Explanations

Switch to web3.py

The web3.py interface for working with contracts is compliant with the web3.js interface which is well documented. This should be an overall win for making use of populus easier for new adopters.

This change will break all uses of the populus.contracts.Contract objects as well as all uses of the blockchain_client. I recognize this is significant but I feel strongly this is the right way to go.

[euri10]

why you don't want to make use of https://github.com/pipermerriam/ethereum-contract ?

[pipermerriam]

@euri10 When I originally created that repository the architecture of the Contract object was dependent on, but decoupled from the interactions with the blockchain through one of the various blockchain clients.

Since then I've done siginificant work on the web3.py codebase, part of which was implementing the revised contract interface that will eventually make its way into web3.js. After working with this contract API for a while I'm convinced it's superior to what I'd initially created in populus.contracts.Contract and subsequently migrated to the ethereum-contract repository.

See https://github.com/pipermerriam/web3.py#interacting-with-contracts for examples of what the web3.py contract interface looks like.

I think there is still an abstraction that allows for the contract object to be fully separate from web3 but it isn't clear to me what that abstraction should be, so currently they are glued together. Thus, I've chosen the implementation at web3.eth.contract over the original populus.contracts.Contract interface.

[euri10]

sounds fair to me and looking at web3.py changes I found it amazing. I was off a few months and it evolved so fast, now that I have more time I'll try help more !

compliments aside, I got a question, maybe I should have asked it on the py-geth repo but as this thread is a discussion let's use it :)

As geth evolves pretty quickly and py-geth being the wrapper around that fast moving client, would it make sense for a given version of py-geth to ensure that geth is at a certain version ?

I tend to use geth develop version most of the time and encountered a "bug" a few months ago because I wasn't using the same geth as the one populus was using,

Enforcinng that would avoid that kind of false positives.

[pipermerriam]

As geth evolves pretty quickly and py-geth being the wrapper around that fast moving client, would it make sense for a given version of py-geth to ensure that geth is at a certain version ?

I've thought about this and I'm unsure what the best approach will be. I plan on keeping the library up-to-date with geth changes to try and respond to changes quickly. I'd be willing to add a minimum version requirement now, but I'm 👎 on enforcing a maximum version number.

Current minimum version would be something like 1.4.10

[pipermerriam]

Closing as most of this is in master and being actively developed.