-
-
Notifications
You must be signed in to change notification settings - Fork 528
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
Handle version conflicts between deps and package deps #2386
Comments
The way it currently works is outlined in the documentation: Switching the order, ie installing the dependencies after the package would certainly break for quite some users, as I have seen configurations where I do see your issue, but I do not see a straight forward solution to it. |
From the POV of tox both are explicitly defined at same level. The problem is to find out when there's a dependency conflict is a hard job. You need an entire solver for that. tox is unlikely to take on that gigantic task. I'd rather make the package installation take on as additional arguments the |
@jugmac00 @gaborbernat thanks, both! I had the same thought about pushing this problem to pip to handle, but wasn't sure how readily that could happen with the tox architecture. I definitely see that doing it that way would be a breaking change, so waiting for tox4 makes plenty of sense. |
So tox 4 is well and out, and this is still an issue, and likely dupe of much older bug #513. But there is a way to solve this long-standing issue without an actual tox change! 🎉 Example
|
I wouldn't be against supporting this behavior part of the core. |
Create a constraints file based on the listed or installed ``deps`` and use it during ``install_package_deps`` to ensure the package dependencies do not override the environment's dependencies. Adds new config keys: * ``constrain_package_deps`` - chicken switch to go back to the legacy behavior of allowing the package deps to override the testenv deps * ``use_frozen_constraints`` - a more strict mode, enforced that the package deps do not conflict in any way with the set of packages installed by ``deps`` Fix tox-dev#2386
Create a constraints file based on the listed or installed ``deps`` and use it during ``install_package_deps`` to ensure the package dependencies do not override the environment's dependencies. Adds new config keys: * ``constrain_package_deps`` - chicken switch to go back to the legacy behavior of allowing the package deps to override the testenv deps * ``use_frozen_constraints`` - a more strict mode, enforced that the package deps do not conflict in any way with the set of packages installed by ``deps`` Fix tox-dev#2386
Create a constraints file based on the listed or installed ``deps`` and use it during ``install_package_deps`` to ensure the package dependencies do not override the environment's dependencies. Adds new config keys: * ``constrain_package_deps`` - chicken switch to go back to the legacy behavior of allowing the package deps to override the testenv deps * ``use_frozen_constraints`` - a more strict mode, enforced that the package deps do not conflict in any way with the set of packages installed by ``deps`` Fix tox-dev#2386
Create a constraints file based on the listed or installed ``deps`` and use it during ``install_package_deps`` to ensure the package dependencies do not override the environment's dependencies. Adds new config keys: * ``constrain_package_deps`` - chicken switch to go back to the legacy behavior of allowing the package deps to override the testenv deps * ``use_frozen_constraints`` - a more strict mode, enforced that the package deps do not conflict in any way with the set of packages installed by ``deps`` Fix tox-dev#2386
Is it possible to install environment |
Well this could be possible but it would probably also break some people who are relying to install dependencies in the first invocation that will be build dependencies for the second one. |
We could make it configurable perhaps via
If build dependencies are declared in pyproject.toml, i believe they are already installed separately. |
That would not work due to the way this tool is designed. Furthermore pip used in various situations not just installing the package dependencies, so changing the install command is out of the question and wrong approach. |
i see; would there be a better mechanism to install the package-under-test together with dependencies of a test environment? I seems like a reasonable setup to me. when I use my package in conjunction with other packages, I would install them together, either by using a requirements file or by installing both in the same When tox installs test environment packages before my package, we are actually testing a slightly different environment. As others pointed out, the followup installation of package-under-test can affect the test environment deps in an undesirable way. |
Any reason you can just add your dependencies into the package dependencies, For example inside an extra group and you need to put it inside deps for tox? |
our use case is compatibility testing. We do use [test] extras, but they add a range, for example 'pyarrow>=3.0.0,<12.0.0'; then, we test several pyarrow versions in tox suites. Having several extras for this purpose seems cumbersome. |
I feel like for that use case you want to use constraint files that you can inject to environment variables in each specific environment instead of using deps. |
Are you referring to the suggestion by masenf@ or there is a simpler example of what that could look like? |
When using tox to run tests for a Python package and installing testing dependencies through
deps
, there is potential for the package'sinstall_requires
dependency resolution to result in a package version that doesn't match the constraint indeps
.Because
deps
is explicitly defined, it feels like it should take precedence (get installed after the package?) or at the very least tox should warn about this situation.I ran into this when testing a package against two Django versions:
The package's
install_requires
ultimately had an abstract dependency who neededDjango>=1.11,<4
, so even for the envs with thedjango4
factor,Django==3.2.12
was being installed. The only real knowledge of this fact was gotten by reading the output list of installed packages, and the lack of a failure I expected to see in Django 4.I was almost inclined to call this a bug, but I have to imagine there are some design decisions at play here that I'm not aware of.
The text was updated successfully, but these errors were encountered: