Closed Anindya-Prithvi closed 2 years ago
What version of brownie are you using? I believe this was addressed in brownie v1.17.1 (https://github.com/eth-brownie/brownie/pull/1310)
@charles-cooper I checked, it's v1.17.2 , I assume it was patched, however the issue doesn't seem to be with brownie... I am not able to run any vyper
commands as well without commenting stuff out
import vyper
fails too with that big message.
@Anindya-Prithvi what else do you have imported at the time you try to import vyper
?
Nothing. A plain python shell instance, and then import vyper
@Anindya-Prithvi thank you, and what's the output of pip freeze
?
@charles-cooper
That's a long output,
aiohttp==3.8.1
aiosignal==1.2.0
appdirs==1.4.4
argcomplete==1.12.3
asttokens==2.0.5
async-timeout==4.0.1
asynctest==0.13.0
attrs==21.2.0
base58==2.1.1
bitarray==1.2.2
black==21.11b1
CacheControl==0.12.6
cached-property==1.5.2
certifi==2021.10.8
cffi==1.15.0
chardet==4.0.0
charset-normalizer==2.0.9
click==8.0.3
colorama==0.4.4
contextlib2==0.6.0.post1
cryptography==35.0.0
cytoolz==0.11.2
dataclassy==0.11.1
distlib==0.3.3
distro==1.6.0
eip712==0.1.0
eth-abi==2.1.1
eth-account==0.5.6
eth-brownie==1.17.2
eth-event==1.2.3
eth-hash==0.3.2
eth-keyfile==0.5.1
eth-keys==0.3.3
eth-rlp==0.2.1
eth-typing==2.2.2
eth-utils==1.10.0
evdev==1.4.0
execnet==1.9.0
frozenlist==1.2.0
fuzzywuzzy==0.18.0
hexbytes==0.2.2
html5lib==1.1
hypothesis==6.27.3
idna==3.3
imageio==2.11.1
importlib-metadata==4.8.2
inflection==0.5.0
iniconfig==1.1.1
ipfshttpclient==0.8.0a2
jsonschema==3.2.0
lazy-object-proxy==1.6.0
lru-dict==1.1.7
meson==0.60.2
more-itertools==8.10.0
msgpack==1.0.2
multiaddr==0.0.9
multidict==5.2.0
mypy-extensions==0.4.3
mythx-models==1.9.1
netaddr==0.8.0
newm==0.1
numpy==1.21.2
ordered-set==4.0.2
packaging==21.3
parsimonious==0.8.1
pathspec==0.9.0
pep517==0.12.0
Pillow==8.4.0
pipx==0.16.4
platformdirs==2.4.0
pluggy==1.0.0
ply==3.11
progress==1.6
prompt-toolkit==3.0.23
protobuf==3.19.1
psutil==5.8.0
py==1.11.0
py-solc-ast==1.2.9
py-solc-x==1.1.1
pycairo==1.20.1
pycparser==2.21
pycryptodome==3.12.0
pyfiglet==0.8.post1
Pygments==2.10.0
pygments-lexer-solidity==0.7.0
PyJWT==1.7.1
pyOpenSSL==21.0.0
pyparsing==3.0.6
pyrsistent==0.18.0
pytest==6.2.5
pytest-forked==1.3.0
pytest-xdist==1.34.0
python-dateutil==2.8.1
python-dotenv==0.16.0
python-pam==1.8.4
pythx==1.6.1
pywm==0.1
PyYAML==5.4.1
regex==2021.11.10
requests==2.26.0
resolvelib==0.5.5
retrying==1.3.3
rlp==2.0.1
semantic-version==2.8.5
six==1.16.0
solc==0.0.0a0
sortedcontainers==2.4.0
tk==0.1.0
toml==0.10.2
tomli==1.2.2
toolz==0.11.2
tqdm==4.62.3
typed-ast==1.5.1
typing-extensions==3.10.0.2
urllib3==1.26.7
userpath==1.7.0
varint==1.0.2
vvm==0.1.0
vyper==0.3.1
wcwidth==0.2.5
web3==5.25.0
webencodings==0.5.1
websockets==9.1
wrapt==1.13.3
yarl==1.7.2
zipp==3.6.0```
That's pretty strange. I can't reproduce the behavior. Are you able to try this with python 3.8?
@charles-cooper Seems to work fine...however the packages are isolated, maybe it's because of some vyper dependency
─(11:55:10)──> python3.8
Python 3.8.12 (default, Dec 7 2021, 05:57:06)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vyper
>>> vyper
<module 'vyper' from '/home/kern/.local/lib/python3.8/site-packages/vyper/__init__.py'>
>>> exit()
─(11:55:33)──> python3.8 -m pip freeze
asttokens==2.0.5
pycryptodome==3.12.0
semantic-version==2.8.5
six==1.16.0
vyper==0.3.1
@Anindya-Prithvi Maybe it has to do with some packages you have in your environment. Does it still work if you use python 3.9 but with a fresh virtualenv?
@charles-cooper Strange, an isolated env seems to work well. Note that I havent played with my python installation in any way apart from getting pip. I fixed my issue by manually forcing an update. (During the update, I saw that eth-brownie depends on lots of old versions of stuff). Since I installed eth-brownie directly, it may have happened that things never updated.
However, without updating stuff, I could run vyper. Why did old_codegen/parser_utils.py
decide to force an exception 🔴 ?
@Anindya-Prithvi you can see https://github.com/vyperlang/vyper/pull/2479 for some details but basically we found that if an imported module overrides decimal.getcontext().prec
, it can mess with how vyper (as a library) handles decimal
literals internally.
Maybe a better behavior would be to issue a warning rather than an exception, at least for production builds. @fubuloubu thoughts?
So I'm not exactly sure why your environment was forcing this exception but it seems like some library in your environment is messing with decimal.getcontext().prec
.
This is what I actually meant. Even though the environment forced a fallback for vyper, the fallback was broken. @charles-cooper Also, I cannot reproduce this behaviour anymore because of updating all the packages, may I close the issue?
Good to close, thank you!
Version Information
vyper --version
): 0.3.1python --version
): 3.9.9What's your issue about?
Error:
How can it be fixed?
Just comment out the lines
More context:
I installed eth-brownie without explicitly handling any vyper packages, upon running
brownie --version
I was greeted with some errors, following the trace I found that the exception was forced? It maybe due to some other issues that such an exception was created which I am honestly unaware of. However, the programs (brownie, vyper) seem to "run" now.