Add nightly build for Vyper

[Saw-mon-and-Natalie]

Having nightly builds as part of GitHub workflows would allow integrating the new unreleased features with other tools. As an example, one can use the nightly builds with @nomiclabs/hardhat-vyper plugin.

[charles-cooper]

@Saw-mon-and-Natalie what is the best distribution channel for these? we already have continuous docker builds and wondering if that works for this use case - https://hub.docker.com/r/vyperlang/vyper. or do we need a continually updated, "nightly" github release?

[Saw-mon-and-Natalie]

I think an additional GitHub nightly release would be nice. That might make it really easy for example with hardhat-vyper plugin to pull the nightly without changing any of the plug-in implementation.

[charles-cooper]

we could have a special release tagged "pre-release" which we automatically update every commit to master.

[charles-cooper]

we could have a special release tagged "pre-release" which we automatically update every commit to master.

i created https://github.com/vyperlang/vyper/releases/tag/pre-release, maybe we can auto-update it every commit to master

[Saw-mon-and-Natalie]

I've created a GitHub workflow for the pre-release. Probably will make a PR for it tonight.

[charles-cooper]

i deleted the release because, unfortunately, it breaks brownie:

i did not test hardhat or ape, i'm curious how we can publish this pre-release version without affecting dev frameworks.

[Saw-mon-and-Natalie]

We could also use a tag like x.y.z-pre-release where x.y.z is the next semver version (adding 1 to the patch version number).

Or following PEP 440, we could use X.YpreZ style pre-release tags.

[fubuloubu]

i did not test [...] ape, i'm curious how we can publish this pre-release version without affecting dev frameworks.

tbh in ape it works perfectly fine installing from any git branch via pypi

[Saw-mon-and-Natalie]

The workflow in PR #2920 can aslo be customized futher to specifiy a custom tag_name. Based on my findings from the different version comparisons, we have:

• ✔ hardhat-vyper plugin uses semver, so tags like 0.3.4-pre-release would work.
• ✔ Brownie and Ape use semantic_version which would also allow a tag like 0.3.4-pre-release
• ⛔ Vyper's setup uses setuptools_scm which tries to implement PEP440 and does not allow for tags like 0.3.4-pre-release, but accepts tags like 0.3pre4. If we go by the 0.3.4-pre-release pattern, we can probably strip the end pre-release in _global_version(version) before feeding it to use_scm_version

[Saw-mon-and-Natalie]

Added a new commit to #2920 to unify the pre-release tag format. Now the x.y.z-pre-release format should work across the board. Already tested the Vyper setup and hardhat-vyper plugin and they work.

We needed to modify the setup.py to make it work:

setup(
   ...
   use_scm_version={
   ...
      "tag_regex": r"^(?:[\w-]+-)?(?P<version>[vV]?\d+(?:\.\d+){0,2}[^-\+]*)(?:[-\+].*)?$"

By modifiying the DEFAULT_TAG_REGEX in setuptools_scm we make sure the ther version part doesn't pick up - character and the suffix after the version portion can start with either - or +.

Vyper contracts can have a pragma version tag like:

# @version 0.3.4-pre-release
a: uint256

and for hardhat projects, the hardhat.config.js file would look like this:

require("@nomiclabs/hardhat-vyper");

module.exports = {
  vyper: {
    version: "0.3.4-pre-release",
  },
};

[charles-cooper]

very cool! my one concern with this is that, pragmas like version >= 0.3.3 will accidentally get compiled with a pre-release version. does the pre-release suffix eliminate that possibility for all build tools?

[Saw-mon-and-Natalie]

@charles-cooper , great point. I'll have to check that.

[charles-cooper]

we are now publishing builds to https://github.com/vyperlang/vyper-builds/, also all docker builds are available through GHCR as of https://github.com/vyperlang/vyper/pull/3435