-1

I have made a small library/application that I intend to distribute. However I want to find out what versions of python can handle my script ? Given that there are many minor and micro versions and two major versions too, how do I go about doing this?

I thought about using docker to do this, but I am not sure if that is the correct way to go about doing things.

Then I thought of using virtual environments, but stopped fearing that because of so many python versions, any mistake I make would end up screwing up my system wide installation.

In general how do other developers find out what python versions would support their packages?

2

Python versions are fairly compatible so you don't have to test each and every minor version. Instead:

  • Test the minimal version you are going to support, e.g. CPython 3.5.
  • Test the latest version, e.g. CPython 3.7.
  • Possibly, test another Python implementation like PyPy 3.7.
  • If you support Python 2.7, test that separately – but note that 2.7 will reach its EOL in 2020, so there is little sense for a new project to support it.

The minimal version you're going to support is a decision you have to make – don't just see which version your code happens to run under. Each new version improves the language (e.g. with new features such as type annotations, async functions, f-strings, ordered dicts, …) and improves the standard library. So take a moment to consider what the minimal level is that you're going to support. In particular, trying to write code that is both valid Python 2.7 and 3.x can be very difficult when considering new syntax features or the different meanings of str (vs. bytes vs. unicode).

For an open source projects, you can easily use cloud-based CI services to do this – one build job for each tested Python version.

For local testing, I personally manually switch between the 2.7 and 3.6 Python versions that are provided by my operating system, using a virtualenv for each with the proper packages. Other people use Tox to run tests across multiple versions, which helps manage the virtualenvs automatically.

Docker based tests take a bit more setup but are still comparatively easy to do. In particular, they make it easy to test across different Python versions without having to install them on your main OS. In my experience, I prefer to have my main development setup outside of Docker so that I can strike the “build” part from the edit–build–test cycle. Docker may be appropriate for CI tests, or if your software has difficult to install dependencies.

  • For most of the part I understand what you are suggesting. Just wanted to confirm, here we can see all the releases. Even if I decide a minimum version to support, there is still a lot of micro versions to test. Do you just test the latest micro version for all the minor versions that you want to support? For example I want to support 3.7, 3.6, 3.5 and 2.7. In that case should I test all the micro versions for 3.7, 3.6 and 3.5 or just the latest ones? – jar Nov 25 '18 at 12:49
  • @S.Raj This depends on what the goals of these tests are. If you need to support a specific version you must test that version. But most of the time, it's sufficient to test any micro-version. After all, those are only issued as bugfix/support releases, and don't include major changes in behavior. The exception is 2.7.x releases where later micro-releases added substantial Python-3 compatibility – there, I'd only support the latest micro-release. – amon Nov 25 '18 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.