Vyper: PyPI vs Source versions

[CarlBeek]

Version Information

• vyper Version (output of vyper --version): Source: 0.1.0b10, PyPI: 0.1.0b10
• OS: osx
• Python Version (output of python --version): Python 3.6.8
• Environment (output of pip freeze): Not super relevant to my issue, but here

What's your issue about?

When building Vyper from source and using PyPI the compiler versions are different. Obviously this is the case, as changes are applied to master (and thus master is not really at version 0.1.0b10 despite what version says), but it caught myself and the team at RuntimeVerification off guard when formally verifying the Eth2.0 deposit contract.

There is nothing explicitly wrong with how things are currently handled, but I feel like it is bad dev-ex to run into this issue (especially considering the nature of code being compiled by Vyper). In addition, note that many projects are going to use PyPI for installation which does not provide a commit-hash (which is ridiculous IMO) so comparing versions is harder than it needs to be. (Also downloading source-code from PyPI doesn't give the .git folders, so checksums don't match either.)

How can it be fixed?

• I think changes to master should be committed to a dev branch (or some similar branch) or version should point to 0.1.0b10-dev or similar.
• A further suggestion: in your build instructions, I recon it would be nice if it recommended (optionally) checking out a tag first before running make.

[jacqueswww]

For your purposes I would suggest build of a git hash in any case. We have tried introducing git hash into the pypi builds but experienced issues see https://github.com/ethereum/vyper/pull/1220. To be honest I don't think having a master run ahead on a specific version number to be a problem as this is very common practice, and makes the github default merging easy. We do provide the releases source for you on the releases page: https://github.com/ethereum/vyper/releases
Perhaps we could revisit introducing the commit hash into --version output ?

[CarlBeek]

While I don't necessarily agree with you that master should be ahead of the latest revision process, I do agree that it is done on the majority of projects and that my personal preferences on how to order a repository shouldn't weigh on that. :)

Perhaps we could revisit introducing the commit hash into --version output ?

What if it is only present in versions that are not on PyPI? (So as not not to run into PyPI's 'local version' rules

Going to close this issue, because there is not something immediately actionable.

[fubuloubu]

What if it is only present in versions that are not on PyPI?

We could have the compiler read it's own files (everything in vyper/) from the install location and hash them together. This should hopefully work regardless of installation via PyPI or from source and give the same answer as all the source files are available.

[daejunpark]

My (stupid) story about this.

I've tried to compile the 0.1.0b10 version from the source, but made a mistake of running make on the master (the default one given by the git-clone), so I did make clean, checkout the tag v0.1.0-beta.10, and did make again. Seeing that vyper --version shows 0.1.0b10, I just assumed that I installed the correct version. But I found that the bytecode generated by my vyper compiler is different from the one released in the Eth2.0 repo, and I couldn't find my mistake (forgetting pip3 uninstall vyper when make clean) quite for a while.

Here is the list of commands to reproduce it:

$ python3.6 -m venv ~/vyper-env
$ source ~/vyper-env/bin/activate
$ git clone https://github.com/ethereum/vyper.git
$ cd vyper
$ make
$ make clean    #### but forgot: "pip3 uninstall vyper"  :(
$ git checkout v0.1.0-beta.10
$ make
$ vyper --version
0.1.0b10        #### but this is not the correct one

More detailed information in vyper --version would be really helpful to debug/communicate in the future. Thanks!!

[fubuloubu]

Alright, I just did what I said above, which should hopefully work for just about everyone? We probably need to test this hypothesis :rofl:

It won't reflect changes to bin/vyper or any of the other scripts, tests, examples, etc., but it should reflect the current configuration of the compiler proper.

[jacqueswww]

@daejunpark @CarlBeek I am cutting b11 tomorrow, and we can test the version output PR of Bryant with that. I would also recommend b11 as candidate for verification as we made quite a number of efficiency improvements, that should help the gas cost of the deposit contract.

[CarlBeek]

Fantastic! I really appreciate how quickly you guys made these changes. Here's hoping it works out! When looking at the IRs between the two versions, there do seem to be a bunch of simplifications in the new version. I'm definitely keen to switch over to b11, but I think that is largely dependent on how much work that would require being redone by the RV team, @daejunpark what are your thoughts?

[daejunpark]

@CarlBeek If the part (to_little_endian_64 and get_hash_tree_root) that I already verified is not affected by the new version, it shouldn't be a big problem for me to bump the compiler version, if your team wants to do.