Improved Python Version Management and Caching on Codeship Basic

Codeship Basic

Reading Time: 2 minutes

We’re excited to announce that we’ve Improved version management and caching for Python on Codeship Basic. You don’t need to change anything right now for existing projects, but you may need to update your configuration to make use of the new functionality.

The main change to version management is that we’re switching from virtualenv to pyenv and no longer rely on the default Ubuntu versions. Virtualenv will continue to work, but you’ll find it easier and quicker to switch to pyenv. To use pyenv, you can either set PYENV_VERSION (instead of PYTHON_VERSION) to your desired version, or put the version in a .python-version file and check that into your repo. We’ll make sure to use the correct version, as long as that version is installed. If you are using a version that is not installed, you will need to install it in your setup commands. By default, the following versions are pre-installed: 2.7.13, 3.4.6, 3.5.3, 3.6.1 though we recommend you specify minor versions (e.g. 3.5) to get patch updated without having to update your setup script every time.

Sign up for a free Codeship Account

You can still install other versions if you’d like; just specify that version in the variable/file and we’ll take it from there. No more scripts or other workarounds.

The new caching is even easier; it’s on by default and you don’t have to change anything. Any dependency you install via pip will automatically be cached between builds.

Naturally, all of this is also explained in our documentation where you can also learn more about how the caching works.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • JD Fagan

    How about support for Miniconda (miniconda3) specifically? Conda is really nice to work with and we use it exclusively in preference over those two.

    • Dennis Newel

      I’ve added it to the list of packages to look at :) we might start off with a helper script that can help you add it to your own projects, but might make it preinstalled later on. The main concern atm is if it’ll play nicely with pyenv and all the other packages.
      there’s also the possibility of using a Pro project instead; you don’t have to deploy docker containers to use it, but it’d allow you to fully customize the build environment to fit your needs. That way there’s no risk of packages not playing nicely as you can pick just the ones you need :)

    • Naturally, all of this is also explained in our documentation where you can also learn more about how the caching works.

  • Unfortunately, this doesn’t work properly with `tox`. A `tox` setup with all supported Python versions (py27,py34,py35,py36) works fine on my machine, which uses `pyenv` to provide the non-system versions on Ubuntu 17.04, but it fails on Codeship Basic. Interestingly, this may not have anything to do with the Python version but rather with the shell setup, as the console script of the package I’m installing is not found.

    It may well be that calling `pyenv rehash` could fix that issue, but this behavior is unacceptable per se. If users manage to install several Python versions in parallel properly using `pyenv` you should manage to do that, too. Please, test your images with a typical `tox` setup that runs tests against all Python versions you support!

    • Dennis Newel

      That does sounds like something we need to have a closer look at. Would you mind submitting a ticket to They’d be able to help you better than i can.

      • Dennis, I’ve opened the helpdesk ticket #13408 today.

    • Dennis Newel

      @bittner:disqus we’ve updated our build servers today to include a call to the rehash, so you don’t have to :)
      Hopefully that should solve your build issues?

  • Evgeny Lychkovsky

    Specifying “PYENV_VERSION=3.6.2” leads to the following warning:
    pyenv: version `3.6.2′ is not installed (set by PYENV_VERSION environment variable)

    • Dennis Newel

      we haven’t added 3.6.2 yet (3.6.1 is the latest we have – i’ll request an update) but you should be able to use `pyenv local 3.6.2` to the setup commands, to get the newest version. On the initial build it does get downloaded, but should then be cached on future builds

      • Evgeny Lychkovsky

        Thanks for the quick reply, @dennisnewel:disqus

        Unluckily, `pyenv local 3.6.2` doesn’t work
        + pyenv local 3.6.2
        pyenv: version `3.6.2′ not installed

        I also tried `pyenv install`, but it also failed..
        + pyenv install 3.6.2
        python-build: definition not found: 3.6.2

        Hope to see 3.6.2 on codeship soon :)


        • Dennis Newel

          puzzling…i have to admit i’m not familiar enough with Python to know why that doesn’t work as it should work on at least older versions.

          We’re looking into upgrading to 3.6.2 as a better solution. would like to know why a simple pyenv install doesn’t work in this case…

          • Evgeny Lychkovsky

            might be an old pyenv version which knows nothing about 3.6.2 and how to install it

          • Dennis Newel

            you’re right! upgrading pyenv fixed the issue. The engineers pushed out an updated version a couple of hours ago so you can now use 3.6.2 out of the box :)

          • Evgeny Lychkovsky

            awesome! thanks