Add CircleCI jobs to run the oldest and newest supported Python versions. #1053
Conversation
.circleci/config.yml
Outdated
There was a problem hiding this comment.
Is it ok to use the python-3.7.4 lockfile with python 3.5 and 3.8?
There was a problem hiding this comment.
In the current version of this we've completely removed these lockfiles, but you're right, it's not safe to use one lockfile against multiple Python versions.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
what does the .Revision suffix do and why do we need it?
There was a problem hiding this comment.
It makes the commit version part of the cache key, which at this time was a way to allow this Python environment cache be shared between a Python tests run and a Cypress run. Changed now to add more information to ~/python_version.md5 to cause it to change once per calendar day instead.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
With this change we're:
- not passing
--systemtopipenv-installanymore. Can you tell me the effects of this? Why were we doing it before? - not passing
--ignore-pipfiletopipenv-installanymore. Can you tell me the effects of this? Why were we doing it before? - not copying the
pipfile.version.locktopipfile.lock. Do we need to rename the versioned lockfile topipfile.lockand commit it to github then in this case?
There was a problem hiding this comment.
--system tells pipenv to use the "system" version of pip rather than the one in the virtual environment. I'm not sure what this was useful for, and I can't think of why it would have been preferred. In any case I've change this so we upgrade the environment local pip right above this, so we should be running from latest.
There was a problem hiding this comment.
--ignore-pipfile is telling it to use just what's in the lockfile, and ignore the actual lib/Pipfile. This is no longer appropriate since we've discarded the use of lockfiles.
Same for the next question.
There was a problem hiding this comment.
I think --system is useful for docker images since we typically don't need to install a venv into a python based image. Are we using a venv in circleci? How about GKE?
There was a problem hiding this comment.
We install a venv here to concentrate our dependency installs into a directory that CircleCI can then cache for us. I'm not sure why --system was passed before or what precisely it did, but we do want these package installs to be in the venv/ directory based on all the rest of the code in this file that caches and restores that directory.
This file is just for CircleCI, so yes, we're using a venv there. Can you expand on the GKE question? With S4T, we are not using a virtualenv (but are doing --user installs right now), but the pipenv-lock make target was only ever used to support CircleCI, I believe.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
Why run cypress with latest python instead of 3.7.4?
There was a problem hiding this comment.
I was just trying to move to using the latest version since I expected that we'd be dropping testing of 3.7.4 in favor of testing the oldest and newest versions we supported, and it seemed odd to keep using an in-between version here. However, I've reverted this since this change resulted in font changes as well, which were undesirable for visual diffing.
fe97455 to
8d212bb
Compare
|
Hi @jrhone, this is ready for review. Apologies for not marking this as WIP before; what you saw was halfway between using and not using the lockfiles, and this goes fully into discarding that concept and instead just utilizing CircleCI's cache for the virtualenv, which is now force-invalidated once per day to ensure we're tracking newer packages on PyPI that still match the requests in Thanks! |
All good! Not sure I understand the rest of your comment though.
Discarding the lock files allows us to use circleci's cache for the virtual env? Weren't we already doing that before, except including the lock files as part of the cache key? Not sure I understand what you're saying here.
So we're automatically updating our dependencies instead of manually doing so by updating our lock file? Couldn't this lead to issues by not having deterministic and repeatable builds? |
.circleci/config.yml
Outdated
There was a problem hiding this comment.
So the circleci cache for installing our python modules will be invalidated every day? Why add the date to the cache key and invalidate on a daily basis?
There was a problem hiding this comment.
There was a discussion in the latter half of an eng standup this week. Both the old and new ways are valid, but have tradeoffs:
Old way:
+ Dependency versions are committed to the source tree, and thus fixed for CI (but not releases or user/developer installs)
- Every time lib/Pipfileis changed, an engineer needs to jump into virtual envs for each Python version we want to test against to regenerate the Pipfile.lock for that version. This cost increases linearly with the number of Python versions we test against.
- As new versions of packages we depend against are released, we don't test against those versions until the next time someone regenerates the lock files, even though our users are exposed to those newer versons.
- When someone makes any change to lib/Pipfile, all dependencies are then potentially updated, batching maybe weeks of failures together (again, users were already exposed to these, since the lockfiles are just for CI, not releases).
New way:
+ No more lockfile generation against every Python version required by engineers when making changes to lib/Pipfile
+ We regularly follow newer versions of packages we depend on that are compatible with the specifications in lib/Pipfile, so we're testing closer to what users would experience, and aren't surprised by breaks that could have already been known the next time we change this.
+ By still caching daily, we don't slow down all CI runs having pipenv's solver run, just one per day.
- When packages we depend on change in a way that breaks a test, we find out seemingly randomly when the daily cache expires.
Those are the tradeoffs I can think of. @tvst verbally okayed going with the daily caching approach.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
What's the effect of not using a pipfile lock anymore and also not including it in the cache key? Isn't it now possible that the versions of modules that we use or their dependencies could change in between deploys and we wouldn't know it? Potentially breaking our deploys.
[Lock files] ensures repeatable, and most importantly deterministic, builds
There was a problem hiding this comment.
As above, the CI job will now once per day solve for the latest versions of our dependencies that are compatible with each other and our specification in lib/Pipfile. The lockfiles were only used by CircleCI, so our PR-based testing flow could unexpectedly break, but on the other hand we'd be less likely to have a break in the wild that we weren't aware of because we were happily using pinned versions.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
I think --system is useful for docker images since we typically don't need to install a venv into a python based image. Are we using a venv in circleci? How about GKE?
.circleci/config.yml
Outdated
There was a problem hiding this comment.
Should we do 3.7.4 here since it runs first and there's no point in running the other two if the first fails? Or what's the thinking for doing it in 3.8?
There was a problem hiding this comment.
The three Python versions all run in parallel. I expect that we'll remove testing on 3.7.4 once we have this in and Tensorflow supports 3.8 as testing against the oldest and newest versions of Python we support should be sufficient. I just proactively moved this to the latest version we're testing against.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
So we're using 3.8.1 as system python but also installing a venv on top? Where is the version for the venv specified?
So we'll update the base docker image version but keep the job name as major minor? What are we saving by keeping the job name to major minor if we have to update the base docker image?
There was a problem hiding this comment.
The venv on top is an existing practice in this CircleCI definition, and I believe it'll use the Docker image's Python version. I believe it's done so that we can utilized CircleCI's caching to capture the venv/ directory and have all of our installed dependencies captured and restored as part of that cache.
There was a problem hiding this comment.
Oh, and regarding the job name, right now our develop branch declares that certain test suites are required to pass in order to perform merges. Those names are annoying to change, 1) because only Thiago can do it, and 2) because when we want to require a new suite we need everyone to rebase to get the new CircleCI configuration in order to run, and thus pass those named test suites.
Because of this, and because Python micro versions come out regularly, I thought it would be better to keep the names as the overall thing we're trying to test, and leave the micro version we're currently using as an implementation detail that doesn't require us to go through that name-change dance.
.circleci/config.yml
Outdated
There was a problem hiding this comment.
Why keep Cypress at 3.7.4 but have jstest run at 3.8?
There was a problem hiding this comment.
I just updated the PR message to say this--I had updated the commit comment, and didn't realize it wouldn't carry over to the PR. :(
Cypress tests failed at 3.8 because of some font difference, while jstest are fine. Again, I updated that just to run against the latest and because I expect Python 3.7.4 testing to go away soon, while this is held back until we solve the Cypress/font issue that arose.
…port. As part of this, we've removed the per-Python-version lib/Pipfile.locks/ files in favor of running without pipenv lock files, and having CircleCI cache our Python environment using a combination of the Python binary, lib/Pipfile, and the current data. This implies that once per day we'll potentially upgrade our Python packages, consistent with any requirements in lib/Pipfile. We will always regenerate our Python environment if lib/Pipfile changes, potentially upgrading any other packages at that time as well. This was deemed acceptable in a conversation with @tvst. This also introduces tests.testutils.requires_tensorflow(), a decorator for tests that require Tensorflow, so that we can skip these under Python 3.8, which Tensorflow does not yet support. In doing this work, it was discovered that we had broken our support for Python 3.5. This required two fixes: o Invocations of "black" were modified to tell it that it needs to retain support for Python 3.5 syntax, which does not permit a trailing comma after "**kwargs" in a function definition. Fixed this in two places in DeltaGenerator.py, restoring Python 3.5 support. o In e2e/scripts/st_magic.py, tests of async generators were made conditional on Python 3.6 or greater. Following this change I expect one follow-up commit, and I made a few voluntary style changes: o Once this makes it to master, I expect to change the "fully-specified" job from python-3.7.4 to python-3.8, leaving only one "inheriting" job at 3.5. Not doing this yet so we can get the new name passing before we change out GitHub status checks to reference it. o The new job names reference the Python major and minor versions they belong to, but *not* the micro version (e.g., 4 in 3.7.4). I think we should be able to advance along these micro/maintenance releases without switching job names. o In the new 3.5 and 3.8 jobs, I removed explicit selection of the Debian version underlying the circleci Debian image we run the tests under. I could just have easily switched these to "buster", the new latest Debian, but I think it's probably better to just go with CircleCI's defaults rather than having to remember to check and update this every year or so. o Moved jstests to run against 3.8, since I'm planning to retire testing against 3.7 soon per the above. I tried doing this with Cypress as well, but ran against diffs due to font differences, so I fell back.
|
Just rebased with |
There was a problem hiding this comment.
Thanks for responding so thoroughly to all my comments!
I was curious about, why not extend lock file usage beyond circle ci, to releases and user/developer installs. Discussed with Nate and sounds like it might restrict the versions of libraries the user is able to install and use alongside streamlit.
One other concern is that it's possible to do an S4T deploy where the user adds no additional requirements, and due to an updated version of the underlying streamlit dependencies, the deploy could potentially break.
Discussed with Nate on a call and sounds like something we'll tackle in the future.
We'll retain testing only against our oldest (3.5) and newest (3.8) supported Python versions going forward. FWIW, the "cypress" test continues to be based on a 3.7.4 image because efforts to upgrade under streamlit#1053 failed due to font rendering differences with screenshots. Handling this upgrade, when needed, will be performed separately, but should not block removal of running the whole Python suite against 3.7.4.
We'll retain testing only against our oldest (3.5) and newest (3.8) supported Python versions going forward. FWIW, the "cypress" test continues to be based on a 3.7.4 image because efforts to upgrade under #1053 failed due to font rendering differences with screenshots. Handling this upgrade, when needed, will be performed separately, but should not block removal of running the whole Python suite against 3.7.4.
…port. (streamlit#1053) As part of this, we've removed the per-Python-version lib/Pipfile.locks/ files in favor of running without pipenv lock files, and having CircleCI cache our Python environment using a combination of the Python binary, lib/Pipfile, and the current data. This implies that once per day we'll potentially upgrade our Python packages, consistent with any requirements in lib/Pipfile. We will always regenerate our Python environment if lib/Pipfile changes, potentially upgrading any other packages at that time as well. This was deemed acceptable in a conversation with @tvst. This also introduces tests.testutils.requires_tensorflow(), a decorator for tests that require Tensorflow, so that we can skip these under Python 3.8, which Tensorflow does not yet support. In doing this work, it was discovered that we had broken our support for Python 3.5. This required two fixes: o Invocations of "black" were modified to tell it that it needs to retain support for Python 3.5 syntax, which does not permit a trailing comma after "**kwargs" in a function definition. Fixed this in two places in DeltaGenerator.py, restoring Python 3.5 support. o In e2e/scripts/st_magic.py, tests of async generators were made conditional on Python 3.6 or greater. Following this change I expect one follow-up commit, and I made a few voluntary style changes: o Once this makes it to master, I expect to change the "fully-specified" job from python-3.7.4 to python-3.8, leaving only one "inheriting" job at 3.5. Not doing this yet so we can get the new name passing before we change out GitHub status checks to reference it. o The new job names reference the Python major and minor versions they belong to, but *not* the micro version (e.g., 4 in 3.7.4). I think we should be able to advance along these micro/maintenance releases without switching job names. o In the new 3.5 and 3.8 jobs, I removed explicit selection of the Debian version underlying the circleci Debian image we run the tests under. I could just have easily switched these to "buster", the new latest Debian, but I think it's probably better to just go with CircleCI's defaults rather than having to remember to check and update this every year or so. o Moved jstests to run against 3.8, since I'm planning to retire testing against 3.7 soon per the above. I tried doing this with Cypress as well, but ran against diffs due to font differences, so I fell back.
We'll retain testing only against our oldest (3.5) and newest (3.8) supported Python versions going forward. FWIW, the "cypress" test continues to be based on a 3.7.4 image because efforts to upgrade under streamlit#1053 failed due to font rendering differences with screenshots. Handling this upgrade, when needed, will be performed separately, but should not block removal of running the whole Python suite against 3.7.4.
* Slider Unit test (#1052) * Moving balloons e2e to unit test * Slider unit test * Testing bounds * Adding comment for the await timeout * Set a classname prefix for atomic styletron css classes (#1047) - fix css conflict between plotly and baseweb slider * Audio unit test (#1058) * Make TSC happy (#1067) * Custom hashing logic for numpy.ufunc types (#1066) * Adding custom hashing logic for np.ufunc * added comment and changed np to numpy * review comments * Fix a couple Python 3.5 regressions caught in other work: (#1070) o f-strings is a 3.6 feature o 3.5 doesn't support a trailing comma after "**kwargs" at the end of a function definition. * Fixing add_rows index calculation (#1054) * Fixing index computation on add_rows * linter * snapshots * reverting snapshot * reverting snapshot * new snapshot from circleci ssh * Advanced caching updates feb (#1040) * Updating caching section in main concepts. * Moving Caching doc over from Google with minor contextual edits. Another pass is still needed. There are placeholders for advanced caching and troubleshooting documents. * Caching issues is still incomplete. * Removing content for push later today. Will add advanced and caching issues next rev. * Addressing Amanda's comments. * Update * Advanced caching and issues. * Edits requested by Thiago * Fixing link * Adjusting main concepts to match the google docs section verbatim * Small tweaks: renamed "items" → "components" and changed verb tenses here and there * Forgot one verb tense change * Rename "items" → "components" * Update PR directly instead of commenting. Co-authored-by: Thiago Teixeira <thiagot@gmail.com> * Fix for the CORS check (#965) * Adding CORS to troubleshooting guide. (#1001) * Adding CORS to troubleshooting guide. * Fixing CORS issues from Thiago. * Changing tip to note. * Separate common issues into multiple docs and improve them. * Talk about S4T Co-authored-by: Thiago Teixeira <thiagot@gmail.com> * Improve docs (#1075) * Improve docs. * Apostrophes * Add CircleCI jobs to run the oldest and newest Python versions we support. (#1053) As part of this, we've removed the per-Python-version lib/Pipfile.locks/ files in favor of running without pipenv lock files, and having CircleCI cache our Python environment using a combination of the Python binary, lib/Pipfile, and the current data. This implies that once per day we'll potentially upgrade our Python packages, consistent with any requirements in lib/Pipfile. We will always regenerate our Python environment if lib/Pipfile changes, potentially upgrading any other packages at that time as well. This was deemed acceptable in a conversation with @tvst. This also introduces tests.testutils.requires_tensorflow(), a decorator for tests that require Tensorflow, so that we can skip these under Python 3.8, which Tensorflow does not yet support. In doing this work, it was discovered that we had broken our support for Python 3.5. This required two fixes: o Invocations of "black" were modified to tell it that it needs to retain support for Python 3.5 syntax, which does not permit a trailing comma after "**kwargs" in a function definition. Fixed this in two places in DeltaGenerator.py, restoring Python 3.5 support. o In e2e/scripts/st_magic.py, tests of async generators were made conditional on Python 3.6 or greater. Following this change I expect one follow-up commit, and I made a few voluntary style changes: o Once this makes it to master, I expect to change the "fully-specified" job from python-3.7.4 to python-3.8, leaving only one "inheriting" job at 3.5. Not doing this yet so we can get the new name passing before we change out GitHub status checks to reference it. o The new job names reference the Python major and minor versions they belong to, but *not* the micro version (e.g., 4 in 3.7.4). I think we should be able to advance along these micro/maintenance releases without switching job names. o In the new 3.5 and 3.8 jobs, I removed explicit selection of the Debian version underlying the circleci Debian image we run the tests under. I could just have easily switched these to "buster", the new latest Debian, but I think it's probably better to just go with CircleCI's defaults rather than having to remember to check and update this every year or so. o Moved jstests to run against 3.8, since I'm planning to retire testing against 3.7 soon per the above. I tried doing this with Cypress as well, but ran against diffs due to font differences, so I fell back. * [mypy] First phase of work on testing Python type annotations. (#1079) o Introduces lib/mypy.ini with a starter set of strictness options. o All changes required to make these options pass. o scripts/mypy created to control running mypy based on suggestion at https://mypy.readthedocs.io/en/latest/existing_code.html#continuous-integration. o scripts/mypy --report emits a "coverage" report, with a summary % at the bottom detailing what % of our non-empty/comment source lines have full type information. Currently at 19.92%, probably based largely on assignments from literals. o 'scripts/mypy --report' is hooked into CircleCI under the python-3.8 job. lib/mypy.ini makes it enforce 3.5-compatible syntax, so I see no reason not to run it under our latest Python version only. o In CircleCI, I modified generation of ~/protobuf.md5 that's used for cache key generation to also include vary if our protoc or protoc-gen-mypy binaries change, as otherwise we'd currently think the prior cache was valid without producing .pyi files. * Widgets unit tests (#1077) * Checkbox unit test * Checkbox unit test * DateInput unit test foundations * DateInput unit test * Multiselect unit test * Testing multiselect overrides * Radio unit test * Selectbox unit test * TextArea unit test * TextArea unit test * TextArea unit test * TextInput unit tests * TimeInput test * Removing unused var * Fixing date * Fixing date * Fix indentation error in fad994c. (#1084) * Fix an incomplete copy for a dict that's then modified. (#1078) New test fails before the change, and passes afterwards. * Handle different Caching error messages (#1068) * handle internal and user errors during hashing * update hashing error messages and traceback handling * add filename and lineno to user hash error message * Retire python-3.7.4 CircleCI project. (#1086) We'll retain testing only against our oldest (3.5) and newest (3.8) supported Python versions going forward. FWIW, the "cypress" test continues to be based on a 3.7.4 image because efforts to upgrade under #1053 failed due to font rendering differences with screenshots. Handling this upgrade, when needed, will be performed separately, but should not block removal of running the whole Python suite against 3.7.4. * Version 0.55.1 (just pointing to new docs) (#1089) * Fix links in docs. * Point Streamlit caching error messages to the right URLs * Improve docs (#1075) * Improve docs. * Apostrophes * Lint * Update version to 0.55.1 * Fix update_version.py to point to correct md file * Somehow the changelog for 0.55 got lost. Fixed. * Somehow the changelog for 0.55 got lost. Fixed. * Remove old advanced caching section from advanced_concepts.md * Fix missing caching URL (#1094) * Allow wider range of int-like types in NumberInput (#1087) * test value integer types inclusive of numpy int64, int32, etc * check all params as numbers.Integer (not just int) * be more accepting of int types in JSNumber * Fix signatures of wrapped DG functions * Lint * Fix bug where icon assets were missing from "make install" * Ugly hack: name screencast files foo.webm.mp4 so it works on sites like Twitter with no modification. * Version 0.56.0 * Add logs to caching/hashing * In hashing.py, only import numpy when needed * Lint * Unbreak audio component * Fix audio tests * Chmod -x all .ts(x) files * Block Streamlit installation if Python < 3.5 * Force Python >= 3.5 * Update snaps. * Update headers and notices * Update changelog * Forgot to add emojis to changelog! * Fix bad merge with audio.test.tsx Co-authored-by: Nahuel Emiliano Rosso Fandiño <arraydude@gmail.com> Co-authored-by: Jonathan Rhone <rhone.j@gmail.com> Co-authored-by: Henrikh Kantuni <henrikh.kantuni@gmail.com> Co-authored-by: Matteo <monchier@users.noreply.github.com> Co-authored-by: Nate White <whiten@georgetown.edu> Co-authored-by: erikhopf <erik.hopf@gmail.com> Co-authored-by: Jackie <52658745+1wpro2@users.noreply.github.com> Co-authored-by: Naomi Most <pnaomi@gmail.com>
* develop: (29 commits) Release 0.56.0 (streamlit#1101) Fix bug where icon assets were missing from "make install" (streamlit#1100) Clean signatures of wrapped DeltaGenerator methods (streamlit#1099) Using widgetId as the key when rendering elements (streamlit#1102) Pass --skip-lock to pipenv under pipenv-install Makefile target. (streamlit#1093) Allow wider range of int-like types in NumberInput (streamlit#1087) Fix missing caching URL (streamlit#1094) Version 0.55.1 (just pointing to new docs) (streamlit#1089) Retire python-3.7.4 CircleCI project. (streamlit#1086) Handle different Caching error messages (streamlit#1068) Fix an incomplete copy for a dict that's then modified. (streamlit#1078) Fix indentation error in fad994c. (streamlit#1084) Widgets unit tests (streamlit#1077) [mypy] First phase of work on testing Python type annotations. (streamlit#1079) Add CircleCI jobs to run the oldest and newest Python versions we support. (streamlit#1053) Improve docs (streamlit#1075) Adding CORS to troubleshooting guide. (streamlit#1001) Fix for the CORS check (streamlit#965) Advanced caching updates feb (streamlit#1040) Fixing add_rows index calculation (streamlit#1054) ...
* develop: (30 commits) [Screencast] Fixing countdown bug (streamlit#1082) Release 0.56.0 (streamlit#1101) Fix bug where icon assets were missing from "make install" (streamlit#1100) Clean signatures of wrapped DeltaGenerator methods (streamlit#1099) Using widgetId as the key when rendering elements (streamlit#1102) Pass --skip-lock to pipenv under pipenv-install Makefile target. (streamlit#1093) Allow wider range of int-like types in NumberInput (streamlit#1087) Fix missing caching URL (streamlit#1094) Version 0.55.1 (just pointing to new docs) (streamlit#1089) Retire python-3.7.4 CircleCI project. (streamlit#1086) Handle different Caching error messages (streamlit#1068) Fix an incomplete copy for a dict that's then modified. (streamlit#1078) Fix indentation error in fad994c. (streamlit#1084) Widgets unit tests (streamlit#1077) [mypy] First phase of work on testing Python type annotations. (streamlit#1079) Add CircleCI jobs to run the oldest and newest Python versions we support. (streamlit#1053) Improve docs (streamlit#1075) Adding CORS to troubleshooting guide. (streamlit#1001) Fix for the CORS check (streamlit#965) Advanced caching updates feb (streamlit#1040) ...
…port. (streamlit#1053) As part of this, we've removed the per-Python-version lib/Pipfile.locks/ files in favor of running without pipenv lock files, and having CircleCI cache our Python environment using a combination of the Python binary, lib/Pipfile, and the current data. This implies that once per day we'll potentially upgrade our Python packages, consistent with any requirements in lib/Pipfile. We will always regenerate our Python environment if lib/Pipfile changes, potentially upgrading any other packages at that time as well. This was deemed acceptable in a conversation with @tvst. This also introduces tests.testutils.requires_tensorflow(), a decorator for tests that require Tensorflow, so that we can skip these under Python 3.8, which Tensorflow does not yet support. In doing this work, it was discovered that we had broken our support for Python 3.5. This required two fixes: o Invocations of "black" were modified to tell it that it needs to retain support for Python 3.5 syntax, which does not permit a trailing comma after "**kwargs" in a function definition. Fixed this in two places in DeltaGenerator.py, restoring Python 3.5 support. o In e2e/scripts/st_magic.py, tests of async generators were made conditional on Python 3.6 or greater. Following this change I expect one follow-up commit, and I made a few voluntary style changes: o Once this makes it to master, I expect to change the "fully-specified" job from python-3.7.4 to python-3.8, leaving only one "inheriting" job at 3.5. Not doing this yet so we can get the new name passing before we change out GitHub status checks to reference it. o The new job names reference the Python major and minor versions they belong to, but *not* the micro version (e.g., 4 in 3.7.4). I think we should be able to advance along these micro/maintenance releases without switching job names. o In the new 3.5 and 3.8 jobs, I removed explicit selection of the Debian version underlying the circleci Debian image we run the tests under. I could just have easily switched these to "buster", the new latest Debian, but I think it's probably better to just go with CircleCI's defaults rather than having to remember to check and update this every year or so. o Moved jstests to run against 3.8, since I'm planning to retire testing against 3.7 soon per the above. I tried doing this with Cypress as well, but ran against diffs due to font differences, so I fell back.
As part of this, we've removed the per-Python-version lib/Pipfile.locks/
files in favor of running without pipenv lock files, and having CircleCI
cache our Python environment using a combination of the Python binary,
lib/Pipfile, and the current data.
This implies that once per day we'll potentially upgrade our Python
packages, consistent with any requirements in lib/Pipfile. We will
always regenerate our Python environment if lib/Pipfile changes,
potentially upgrading any other packages at that time as well. This was
deemed acceptable in a conversation with @tvst.
This also introduces tests.testutils.requires_tensorflow(), a decorator
for tests that require Tensorflow, so that we can skip these under
Python 3.8, which Tensorflow does not yet support.
In doing this work, it was discovered that we had broken our support for
Python 3.5. This required two fixes:
o Invocations of "black" were modified to tell it that it needs
to retain support for Python 3.5 syntax, which does not permit a
trailing comma after "**kwargs" in a function definition. Fixed this in
two places in DeltaGenerator.py, restoring Python 3.5 support.
o In e2e/scripts/st_magic.py, tests of async generators were made
conditional on Python 3.6 or greater.
Following this change I expect one follow-up commit, and I made a few
voluntary style changes:
o Once this makes it to master, I expect to change the
"fully-specified" job from python-3.7.4 to python-3.8, leaving only
one "inheriting" job at 3.5. Not doing this yet so we can get the new
name passing before we change out GitHub status checks to reference it.
o The new job names reference the Python major and minor versions they
belong to, but not the micro version (e.g., 4 in 3.7.4). I think we
should be able to advance along these micro/maintenance releases
without switching job names.
o In the new 3.5 and 3.8 jobs, I removed explicit selection of the
Debian version underlying the circleci Debian image we run the tests
under. I could just have easily switched these to "buster", the new
latest Debian, but I think it's probably better to just go with
CircleCI's defaults rather than having to remember to check and update
this every year or so.
o Moved jstests to run against 3.8, since I'm planning to retire testing
against 3.7 soon per the above. I tried doing this with Cypress as
well, but ran against diffs due to font differences, so I fell back.