Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage with envlist? #58

Closed
denizdogan opened this issue Apr 27, 2021 · 2 comments
Closed

Usage with envlist? #58

denizdogan opened this issue Apr 27, 2021 · 2 comments
Labels
question Further information is requested

Comments

@denizdogan
Copy link

How is this meant to be used with envlist? I'm not sure I fully understand the purpose of this project, but I have this in my tox.ini:

[tox]
skipsdist = True
envlist = py{37,38,39}-django{20,21,22,30,31,32}

[testenv]
deps =
    django20: Django==2.0
    django21: Django==2.1
    django22: Django==2.2
    django30: Django==3.0
    django31: Django==3.1
    django32: Django==3.2

The idea is to use a build Matrix with Python 3.7-3.9 and Django 2.0-3.2, you get the idea. However, when I use this plugin, it always installs Django 3.2 because that's what's in my lockfile.

So maybe I am misunderstanding the purpose of the project, I'd appreciate if someone could shed some light on this.

@enpaul enpaul added the question Further information is requested label Apr 27, 2021
@enpaul
Copy link
Owner

enpaul commented Apr 28, 2021

Hi @denizdogan, this is an excellent question and a use case I've been meaning to add to the documentation.

The main purpose of this project is to eliminate problems in your project's tests that are caused by subtle variations in dependency versions. For example, if your project requires foobar>=1.2,<2.0 then poetry will identify the latest compatible version (lets say 1.2.3) and save that version in the lockfile. This way every time someone downloads your lockfile and runs poetry install they will always get version 1.2.3, even if the upstream maintainers release 1.3.0. However pip (which is called by tox when it's provisioning a test environment) will simply take the compatible range and install the latest version that matches (1.3.0, in this case), sometimes even if another dependency somewhere else is explicitly incompatible with that version. Because your local development environment (as maintained by poetry) is now using different package versions than your test environment (as maintained by pip/tox) your test environment can encounter problems that cannot be replicated in your local development environment. And because these problems can be introduced by upstream maintainers releasing new versions of their packages, these problems can happen anytime and seemingly for no reason.

The tox-poetry-installer plugin trys to prevent these problems by always taking the versions of dependent packages from the poetry lockfile so that test environments are always using a subset of the exact dependencies installed to to your dev environment. This ensures that problems encountered in your test envs are always as-close-as-possible-to-always reproducible in your local dev env (and vice versa).

So now to your question (sorry, I realize this is long winded). In this case the variation in the dependencies are part of what you're looking to test in your tox environment, so as you noted always installing the same version from the lockfile doesn't make sense. However, you can still use this plugin to benefit the stability of your environments. Of course I don't know your exact use case, but let's imagine you're using pytest and the pytest-cov plugin to run the tests that check compatibility with django. The below config sets up this environment, but installs the pytest packages from the lockfile:

[tox]
skipsdist = True
envlist = py{37,38,39}-django{20,21,22,30,31,32}

[testenv]
deps =
    django20: Django==2.0
    django21: Django==2.1
    django22: Django==2.2
    django30: Django==3.0
    django31: Django==3.1
    django32: Django==3.2
locked_deps =
    pytest
    pytest-cov

This isolates the "variable" that you're testing (the django package version) as the only variation from environment to environment. All other dependencies are known to be identical and so subtle differences can't be the source of compatibility problems.

Of course if the above doesn't look like your use case then the answer may be a lot simpler: this plugin may not actually be of much benefit to your project. I see you have the skipsdist = true option, so the plugin isn't installing your project's main dependencies, and if the only other package you need to install is the django pakcage then there's no reason to take the lockfile into account at all. But if you do need to ensure that package versions in your local dev environment match those in your tox test environment, then this plugin may be a solution for you.


Sorry for the long answer, I hope it cleared some things up, but in case it didn't please let me know and I'll try to clarify. I've added #59 to remind me to add a note about this use case to the docs.

@denizdogan
Copy link
Author

@enpaul Thanks for your detailed explanation, much appreciated!

This is a good reminder for me to always include the full configuration even though it may seem unnecessary at a first glance. My issues arose from having this further down in my tox.ini file:

commands =
    poetry install -v  # DELET
    poetry run pytest

So removing that one poetry install -v line fixed my problems. Thanks again for taking the time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants