browniebroke
commented
2 years ago To workaround this, I'm using that image (which has a lot more than we need), and tell pyenv to use Python 2.6. We cannot do
pip install <package name>as it fails with SSL errors, hence I'm downloading the packages with curl (I took the URLs from the latest green build in Travis), and installing from tarballs/wheels.
I've switched to a lighter image mrupgrade/deadsnakes:2.6 which has Python 2.6 pre-installed.
jmadler
edschofield
This pull request builds on top of #601. It is an attempt at rethinking the CI pipeline by splitting each Python version on a separate job.
Given that this project might be supporting EOL Python versions beyond what GitHub is willing to do, I've setup all the jobs to run in Docker, even though only Python 2.6 doesn't seem supported. Sadly, I think this is one of the rare versions to not have an official Docker image.
I've spent some time trying to build one from scratch, but it's much harder than I would expect it to be, mainly because
get-pip.pyisn't working anymore. Here is what I've tried which didn't work:From what I can see, the image
jmadler/python-future-builder:latestworked at the time, because it was built before PyPI changed something around their certificates last year.To workaround this, I'm using that image (which has a lot more than we need), and tell pyenv to use Python 2.6. We cannot do
pip install <package name>as it fails with SSL errors, hence I'm downloading the packages with curl (I took the URLs from the latest green build in Travis), and installing from tarballs/wheels.I think the tests are now running on all versions, but are broken on Python 2.6, ~3.8~ and 3.9.
I got rid of the linting script as it was also failing, I can add it back as a separate job (or using pre-commit.ci), but it's probably a separate discussion.