eth-brownie / brownie Goto Github PK

Create a new mode specifically for gas profile comparisons that integrates with git to run the same test across multiple branches and output the results.

This could also force a rethink about the brownie project folder structure..

This is messy. I am a messy coder. Reformatting needed.

Based on implementing #18 and #19, it should be possible to introduce something similar to this:

https://github.com/sc-forks/solidity-coverage

The version of the EVM is currently set in solc as well as ganache. It's possible to have different settings for each, which causes issues deploying contracts. There should be a simple way to check / modify the setting in both places at once.

..and when a contract is deployed, need to be able to see that tx as well.

Adding support for ganache's evm_snapshot, evm_revert, evm_increaseTime, and evm_mine will greatly increase efficiency when running tests.

Should be able to provide mnemonics that are compatible with metamask.

https://github.com/michailbrynard/ethereum-bip44-python seems like a good place to start.

Something like this...

notify.changed(token.balanceOf, 0x12345, callback_fn)

So that you can have functions automatically execute based on state changes in the blockchain. Could have a lot of simple premade ones... a sound is played, funds are sent, etc

-Display internal transfers
-Retrieve return values from transactions
-Display log events on reverted transactions (when estimateGas is disabled)

Use of debug_traceTransaction is heavy on a node and not available from infura, so this should be an optional config setting.

-up arrow to get previous command
-left arrow to go back and edit already written text

the current setup with assert and fn.revert() is inconsistent, hard to understand at a quick glance, and generally not good enough.

Instead of:

id_ = tx.events[2]['data'][0]['value']

it would be much simpler to type:

id_ = tx.events['NewAuthority']['id']

Need to give this some thought. Multiple firings of the same event in the same tx will complicate it, but there must be a way..

• How libraries are handled
• How brownie handles type conversions - requires #57
• Debugging
• Coverage evaluation
• Return value formats
• Instructions for using geth instead of ganache - requires #87 (sort of, added a local RPC section)
• Using other networks
  • Infura and project tokens (truffle does this well)
• Working with multiple projects at once
• The Brownie GUI
• brownie.test API
• Contributing

There should be a way to remove items from the Accounts and ContractDeployer containers. Make sure it modifies persistent state as well.

• apply checksum to strings before doing comparisons
• highlight ContractTx and ContractCall classes in a different color when using dir() - or add a new method functions() ?
• some builtin methods should not be available - possibly sub-typing list and str is the wrong approach

Instead of locally storing them at brownie/projects, follow the example of Truffle and make something like this:

https://github.com/truffle-box

Then add a function to the CLI to query a list and clone specific repos.

brownie/test/coverage.py is by far the messiest, hardest to follow code in this project. It's only use is to evaluate test coverage for later visualization in opview. This code should be cleaned up, commented, and potentially moved out of brownie and into opview, so that the test coverage tooling can be used on non-brownie projects.

Issue

• During tests it's useful to have error strings in every revert/require, so we can make sure a function is failing at the expected point
• Added gas costs make the strings less attractive when deploying on the mainnet

Idea

• Brownie should have a config setting that automatically regex's and strips a contract or any error strings that begin with "dev:" before deploying it on specific networks

We are already using this string format in SFT, so this functionality will be added at some point in the near(-ish) future.

The current approach to command line args is... messy.

Pretty self explanatory.

utils/compiler.py has some excessively long functions and likely redundant code that wasn't dealt with in the move from 0.9.5 to 1.0.0b1. Additionally, network.contract.py line 62 is modifying the build data, and it's being dealt with via copy.deepcopy in the compiler which is hacky af.

Need to properly deal with this module and bring it in line with the rest of the project.

The design is poor and the logging settings in config.json are very confusing. This area can be improved upon greatly.

In making brownie install via pip I came up with dependency conflicts and realized that the two1 library handling mnemonics hasn't been maintained in over 2 years.

With commit 616122f I've temporarily removed the accounts.mnemonic method. I will reintroduce it once ethereum/eth-account#33 is merged, or if another solution presents itself.

This would be so much simpler than requiring it to be set in the config file, and we could allow for projects to use different compiler versions for different contracts.

Hi,

Would it be possible to have a native brownie compile or brownie build command?

It's common to want to compile the contracts without running the tests or a specific script. It will also facilitate the integration with third-party tools; we are looking at adding native brownie support to all the crytic tools (including Slither, Echidna and Manticore).

Thanks!

Instead of the current design, the brownie console should use compile and check for SyntaxError and IndentationError to determine if there are syntax errors or if the user is entering a multiline statement. The current approach can lead to a strange form of hell where syntax is impossibly broken but the statement won't end due to uneven brackets.

saving accounts is a good start, but it should also be able to save addresses of deployed contracts and possibly even local variables

After broadcasting a tx, it should be possible to immediately return to the console. Should also be able to broadcast subsequent tx's before the previous one confirms, or replace one that isn't confirmed.

https://github.com/trailofbits/slither
https://github.com/ConsenSys/mythril-classic

Should be relatively straightforward to call both of these from Brownie when running tests.

Error message -

Error 403 - This web app is stopped.
The web app you have attempted to reach is currently stopped and does not accept any requests. Please try to reload the page or visit it again soon.

If you are the web app administrator, please find the common 403 error scenarios and resolution here. For further troubleshooting tools and recommendations, please visit Azure

Steps to reproduce:

1. git clone https://github.com/HyperLink-Technology/brownie.git
2. cd /brownie
3. docker build .

Hi,

You might be already aware, but if brownie is installed through pip, web3 will not be installed, leading to this error:

ModuleNotFoundError: No module named 'web3'

An installation through git does not have the issue.

Instead of just:

Transaction sent: 0x8600fa55b6dd527913b55b97ac7e0e390a1f1b6bc1d5bb6db6aede83128e60d5
Transaction confirmed - block: 17 gas spent: 45692

it would be nice to see the contract name, and name of the function being called.

• Fix numbering when tests fail or skip
• Show count/total across all tests whenever starting a new module
• Show total time to complete each test module and to complete all tests
• Include contract name with function in coverage report (SafeMath.add instead of just add)
• Show combined coverage % for entire contract

The topic for an event will be identical regardless of if values are indexed or not, but eth_event will fail if the provided ABI doesn't have the same indexing. Need some error handling in place for this situation.

Current integration TODO list:

• basic compiliation and interaction
• minification
• dependencies
• only recompile if changed
• decimal data type
• statement coverage
• branch coverage
  • if/else
  • assert
• custom error strings
  • over/underflow checks
  • out-of-bounds array index
  • paying to a nonpayable function
  • modulus 0
• dev revert strings
• updates to GUI
• test cases
• documentation

With 1.0.0 release, exceptions now all live at brownie/exceptions.py. Need to go through the code and find all the places that built-in exceptions are being used but don't quite fit, and create more specific / applicable custom exception classes.

Related to #65 - There is a lot of overlap in the code between these modules, they should be refactored, cleaned up, simplified..

Common code could be moved to a module in brownie/tests perhaps.

https://github.com/ethereum/eth-tester

Unsure if eth-tester supports debug_traceTransaction so this might require some work on the other side.. If it is available, should be relatively easy to integrate. More python, less JS is good :)

...otherwise you get an error.

The logic for when to recompile a contract needs to be improved upon.

At minimum, there should be a link to the github repo so people know which mixes are available.

Need to through the docs in detail, and update them to reflect all the new changes. Also consider a more general reorganization.

Priority is on installation and quick start, in the mean time a disclaimer should be in place warning that some sections are out of date.

Should also address #41 in this update.

Reports should be stored in separate files. Right now if you run a single test you lose the results for all previous tests. In a large project it can take a long time to execute the entire test suite, losing all the coverage data is not fun.

When brownie checks if a contract should be recompiled, the same process can be used to delete coverage info for tests that have been changed.

Include it as an optional setting in config.json - allow transactions to have a manual gas limit set so that they can be broadcasted even if they will revert. This will also require modifying how contract transactions are formed using Account.

Brownie is much more forgiving of types than web3.py when calling a contract.

_format_inputs in contract.py handles type conversions, but when the type is too far off what's expected, it sometimes raises very confusing exceptions. Exception handling here needs to be expanded upon heavily. The documentation should explain exactly what is and isn't allowed, and how types are implicitly converted.

-allow commands to span multiple lines
-better error reporting: "SyntaxError on line 1" is not very useful

This will save a lot of time looking at code...

Fairly self explanatory. pytest is well known and battle tested, so probably a better approach than my own self-rolled alternative :)