Install Python 2.7 and 3.6 on Centos6 base image through Pyenv#7064
Conversation
Eric-Arellano
left a comment
There was a problem hiding this comment.
Thank you Danny for cleaning this up! Looks great.
We’ll need to figure out how to publish this to Docker once it’s merged.
|
As the CI run was shown to work on Travis in 05e7b67, I've moved the pyenv changes from |
|
I pushed e641c3e first with changes made to both |
|
Was having trouble with Docker on my local machine not having enough space even after I deleted all of the images locally. Will look at this with fresh eyes tomorrow. |
illicitonion
left a comment
There was a problem hiding this comment.
Looks reasonable, but I don't know enough about pyenv to be useful - leaving to other folks who know what they're talking about :) Thanks!
Realized we don't need to be blocked by pantsbuild#7064, although it should certainly be addressed soon after by a followup PR.
12c12db to
1be1a25
Compare
|
|
|
With #6981 squash-merged on top of the current commit, we get this travis log for building the py3 linux pex (from this travis run on my fork), which shows it failing at importing sqlite, which is expected until the changes to EDIT: After talking to @Eric-Arellano, that appears not to be the case. Will make another squash merge temporarily adding the sqlite-devel package in the travis_ci dockerfile to verify it works with the |
|
There are failures in the branch I've pushed my to own fork which squash merges |
### Problem Right now our CI exclusively uses Python 2 under-the-hood. It tries to test Python 3 support by setting`--setup-python-interpreter-constraints` to Python 3, but this only constrains subprocesses like tests and is not the same thing as fully supporting Python 3. We want our CI to test using both Python 2 under-the-hood and Python 3 under-the-hood, because for the next two releases are promising users that either interpreter is fully supported. Daily CI should run primarily with Python 3, and the nightly cron job should check for Python 2 regressions. ### Solution Use the new `./pants3` script added in #6959. #### Installing Python 3 on each shard * OSX: git clone pyenv to consistently install 3.6.8. Necessary because some older images come with an outdated version of pyenv. We don't use Travis's `language` feature because several shards are supposed to be `language: general`. * Linux build engine, temporarily modify `travis_ci/Dockerfile` to download pyenv and install Python 3. This change is being pulled out the `centos6` image in #7064 to avoid rebuilding Py3 every CI run, but it must be published to Docker hub so will be addressed in a followup PR. * Normal Linux shards, use Travis's `language: python` feature #### Add integration test blacklist 23 integration test targets are failing when ran with Py3 under-the-hood, so we restore support for an integration test blacklist. This allows us to track Py3 fixes we make and to collaborate more easily. Further, the contrib tests, linter, and osx rust shards when ran with Py3. So, we run these 3 shards and the blacklist with a Py2 pex but Py3 subprocesses, which is what we currently do in master. #### Expand Cron job We add non-integration test jobs to the nightly cron run to check for any regressions in shards like `Linux build wheels`, now that we run daily with a Py3 PEX and need to check that they still work with a Py2 PEX. #### Default to Python 3 in CI Defaulting to Py3 reflects that we are transitioning towards exclusive Py3 use. This is not user-facing, and only impacts the `.travis.yml` code, so this change is safe to make, whereas we want to wait to rename `./pants3` -> `./pants` until it is a bit more robust. ### FYI - new .travis.yml idiom This required a major rewrite of `.travis.yml` to avoid duplication. The new idiom we use when defining a shard is to have a `base_my_new_shard` which defines the minimum amount of config necessary for that job, and then to have a `py2_my_new_shard` and `py3_my_new_shard` that extend that base along with their corresponding OS + python version config.
776cb9b to
13f7b4c
Compare
add openssl and other required libs to the travis_ci dockerfile
afea5f2 to
a06bfbe
Compare
|
I have pushed changes which address the recent review comments and also allow the
|
Eric-Arellano
left a comment
There was a problem hiding this comment.
Good idea with the plan to make this robust to when we publish to Dockerhub!
Eric-Arellano
left a comment
There was a problem hiding this comment.
Re-reviewed code changes and they all look good.
Some suggestions for the PR title and PR description:
- Rename to "Install Python 2.7 and 3.6 on Centos6 base image through Pyenv". Pyenv is more of an implementation detail than the important takeaway.
- The cache from #7470 does not apply to the docker images. For the Docker images, we rebuild Python 3 every time.
- In solution section, change to
Use Pyenv to install Python 2.7 and Python 3.6 - Maybe worth mentioning why we use Pyenv to install Python 2.7 rather than the apt installed Python. I think the main motivation is symmetry.
| @@ -21,10 +21,12 @@ RUN yum install sqlite-devel -y | |||
| ENV PYENV_ROOT "${PYENV_ROOT:-/pyenv-docker-build}" | |||
There was a problem hiding this comment.
@cosmicexplorer can you please remove lines 19 and 20: RUN yum install sqlite-devel -y. We don't need them anymore.
### Problem The conclusion of #7064 was, after `pantsbuild/centos6:latest` was updated, to remove the pyenv bootstrapping in `travis_ci/Dockerfile` as it was now being done in the centos6 base image. ### Solution - Remove the marked section. ### Result This will speed up all Docker shards that had Py3 installed by 2-3 minutes. So, Linux build engine Py36 and Linux build wheels abi3. This means overall CI is about 5 minutes faster, and the bootstrap stage 2-3 minutes faster, which is especially significant since that blocks starting other tests. Finally, this means everywhere we run Pants in CI, we have Python 3 installed now (instead of having to install it again!).
…7418) ### Problem We will in #7064 start using Pyenv to install Python 2.7 in the base Centos6 image. This will conflict with our Linux UCS2 shard, which currently uses Pyenv to install Python 2.7 with UCS2 instead of the default UCS4. ### Solution Tweak the Dockerfile to avoid any ambiguity with Centos6 image: * Rename the Python version env var to not conflict by marking it as `UCS2`. * Check if `PYENV_ROOT` is already defined. * Check if `PYENV_ROOT` already exists before git cloning to avoid a git failure. The key line is `${PYENV_BIN} global ${PYTHON_27_VERSION_UCS2}`, which will override whatever `${PYENV_ROOT}/shims/python2.7` used to point to.
### Problem We have used a python 3 interpreter in CI for a while now, using `pyenv` to install this in our Dockerfiles instead of relying on CentOS's `scl` features, which don't allow for multiple pythons at a time. Using `pyenv` to install Python 2.7 as well instead of relying on the package manager allows us to upgrade or modify the image without screwing up our Python installation. That work began in this PR and ended up in #6981, #7352, #7418, #7483, and more, but it then led to having to duplicate code across `travis_ci` and `travis_ci_py36` Dockerfiles. Using `pyenv` to install python in our `travis_ci` images also involves a significant setup time in bootstrap phases to install our desired pythons. Installing Python in the CentOS 6 base image avoids having to install Python at all in our CI, which saves us minutes in the bootstrap phase. ### Solution - Use Pyenv to install Python 2.7 and Python 3.6 in the `centos6` Dockerfile. - Remove `travis_cy_py36`. - Modify the `travis_ci` Dockerfile to bootstrap pyenv itself if not available. ### Result We get some CI time back in the bootstrap phase. ### TODO - [ ] merge this PR - [ ] publish the new `centos6` image to dockerhub at `pantsbuild/centos6:latest` - [ ] merge a followup PR removing the manual pyenv bootstrapping from the `travis_ci` image.
Problem
We have used a python 3 interpreter in CI for a while now, using
pyenvto install this in our Dockerfiles instead of relying on CentOS'ssclfeatures, which don't allow for multiple pythons at a time. Usingpyenvto install Python 2.7 as well instead of relying on the package manager allows us to upgrade or modify the image without screwing up our Python installation.That work began in this PR and ended up in #6981, #7352, #7418, #7483, and more, but it then led to having to duplicate code across
travis_ciandtravis_ci_py36Dockerfiles. Usingpyenvto install python in ourtravis_ciimages also involves a significant setup time in bootstrap phases to install our desired pythons. Installing Python in the CentOS 6 base image avoids having to install Python at all in our CI, which saves us minutes in the bootstrap phase.Solution
centos6Dockerfile.travis_cy_py36.travis_ciDockerfile to bootstrap pyenv itself if not available.Result
We get some CI time back in the bootstrap phase.
TODO
centos6image to dockerhub atpantsbuild/centos6:latesttravis_ciimage.