Support lock dependencies with lowest solvable versions

[JorgeGarciaIrazabal]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Context

When I am implementing a library, it would be super useful to run my tests with all the supported dependencies defined with the constrains in pyproject.toml. This will prevent errors in production when, for example, I use some new features of a dependency and forget to update the dependencies constrains (this is hard to identify when you are coding).

Because running the tests with all the possible combinations of all your supported libraries is virtually impossible, maybe running them with the lowest versions solvable solution and also the highest (I think this is the default behavior)

Proposal

• add the flag --use-lowest-versions to the cli entrypoints (install, sync, lock, shell, and run)
• these commands will create and/or use a different lock file poetry.lowest.lock
• a different venv will be created by just adding lowest after the project name like this: {project_name}-lowest-{id}-{python-version}

Main simple use case

In ci do the following steps

• Install environments

>>> poetry install 
>>> poetry install --use-lowest-versions

• run tests for highest versions

poetry run pytest  --junit-xml pytest.xml

• run tests for lowest versions

poetry run --use-lowest-versions pytest  --junit-xml pytest.xml

Note: I would appreciate if anyone has a better name for the flag (naming is the hardest part :P)

Also, I looked a the code and I think I know where add this logic, I can create a PR if you like the idea

[sinoroc]

You might want to look into tox, it is very good at this kind of things.

[JorgeGarciaIrazabal]

You might want to look into tox, it is very good at this kind of things.

Thank you for the rapid response @sinoroc.

tox could definitely help to run the tests, but this feature is for defining the dependencies instead. (As far as I know, you have to provide the dependencies to tox)

This feature will simplify the definition of an environment with the lowest possible dependency versions which could potentially be an environment where final users could install the package with pip install {my_library}.

So for example, if my library support flask = "^1.0.0" and I start using a feature that was only implemented in flask 1.1.0, this problem will be hidden as you will normally test your library with an environment with the latest versions solved with poetry lock.

As you can imagen, this could cause bad user experience as users with flask 1.0.0 will be able to install my library but still get errors that could look like ModuleNotFoundError: No module named flask.{new_feature}

Sorry if tox offers this feature already that I am not aware of, if so, could you please share an example @sinoroc ?

[sinoroc]

tox allows you test against multiple versions of the same library, for example here:

• https://stackoverflow.com/q/59377071

So you would need to specify a test environment that tests your project against the lowest boundary of the version range for flask for example, and one for the highest, and then a couple more significant ones in the middle.

Actually, usually you would pick some significant libraries your project relies on: flask is a perfect example. And then create one test environment for each major.minor version that your project is supposed to support. So you would have a test environment for flask==1.0.* and a test environment forflask==1.1.*.

And then if your test suite, actually covers all the features of flask that your project uses, then you will immediately know if something is wrong when the test suite fails in one of the test environments.

[JorgeGarciaIrazabal]

exactly, that is a way to do it, I guess I am just lazy that I don't want to do that manually and prefer to have poetry to define my lower and higher dependency boundaries in a "smart way".

Although there is manual configuration that can be done, I still think having this feature can improve the dev-cycle and be useful for multiple cases.

I found in the code that by just changing the reverse flag here:

poetry/poetry/puzzle/provider.py

Lines 136 to 142 in 2aab9bc

	packages.sort(
	key=lambda p: (
	not p.is_prerelease() and not dependency.allows_prereleases(),
	p.version,
	),
	reverse=True,
	)

it will prioritize the lower versions and then by just connecting with the commands, it can easily be implemented (hopefully)

[sinoroc]

From my point of view, this is a case where you really want to have a human brain deciding which combinations of versions of dependencies should be tested.

prefer to have poetry to define my lower and higher dependency boundaries in a "smart way"

Not sure what you mean here.

Poetry really gives you just 1 combination, which does not necessarily end up including the highest bound of your dependency.

Unless everyone using your library also uses your lockfile (which is most likely not the case for obvious reasons), everyone will likely end up with a different combination of dependencies, nothing poetry can do about it, different tools have different dependecy resolution algorithms that deliver different results. So it is up to you to pick up some meaningful combinations of dependencies to test against.

Dependencies and dependencies of dependencies are not as simple as one might think, testing only the lowest and the highest is not meaningful in my eyes. Again poetry just offers you 1 working combination, not the "highest" bound (whatever that could possibly mean).

[JorgeGarciaIrazabal]

Thank you @sinoroc your feedback is always very clear and instructive, but I have a couple of comments.

From my point of view, this is a case where you really want to have a human brain deciding which combinations of versions of dependencies should be tested.

related to that ☝️ , I kind of think the opposite. In an ideal world, you should only have to define your dependencies constrains (we do this in pyproject.toml already) and then a computer would go through the dependency graph and decide what are the best set of dependencies to tests. I am not saying this is easy to do or if poetry should be responsible for it, but I think it is theoretically doable and this feature request is a step closer to that world.

Poetry really gives you just 1 combination, which does not necessarily end up including the highest bound of your dependency.

About this ☝️ , poetry claims to get the latest versions of the dependencies with the update command https://python-poetry.org/docs/cli/#update

# update

In order to get the latest versions of the dependencies and to update the poetry.lock file, you should use the update command.

and looking at the code and it looks like the lock command does something similar.

Also, I agree with you that testing only the lowest and the highest dependencies might not be fully meaningful in some cases, but it can complement the manual approach you mentioned before (https://stackoverflow.com/q/59377071) and definitely improve the current normal behavior of only testing you application once.

Any way, I feel like this can help the community, but if you don't think this is useful, I can build an external script to solve my issues otherwise

Thank you again for the patience and all the feedback :)

[sinoroc]

I totally see your point, and I wish it were possible to automate this as you described (more or less), I am just not confident it is technically feasible in a meaningful way (there are just way too many moving parts, finding one working combination is already hard enough). Just my personal opinion, the maintainers will decide. Maybe there is a compromise to be found somewhere, or probably this could be feasible with a plug-in.

[Spectre5]

I really like this idea and was looking for this functionality myself. A library will often try to keep the version dependencies as open as possible so that it is as compatible as possible with other libraries that may be installed into the same virtual environment. But since you're local environment may have newer library versions (in your lock file), it is easy to use functionality from a library that was introduced after your lowest allowed library versions. Of course you cannot check all combinations of dependencies, but I think checking all of the minimum permissible versions and the latest/newest versions would give pretty strong support if yours test coverage is good.

[oprypin]

I think, rather than asking Poetry to solve for the lowest possible version, one could ask it to install exactly the lowest specified versions of everything.

On one hand, this can seem restrictive, as one would need to manually fix versions until this becomes solvable. But on the other hand, I think it's better, because

1. isn't it very good to always be sure that the exact combination of all lowest versions is installable?
2. if Poetry did have such a feature in the solver, what use would it be, seeing as it would resolve to some unknown versions, rather than the ones you wrote? (i.e. you're still not sure that your min versions are truthful)

And, well, then it also becomes definitely technically feasible.

For now I'll be doing literal replacement of "^1.2.3 to "==1.2.3...

sed -i -E 's/"(\^|>=)([0-9])/"==\2/' pyproject.toml

And I'm actually happy with that, because I don't pull in Poetry for my CI anyway.

My CI: oprypin/mkdocs-literate-nav@ffab008

[pohlt]

IMHO, this feature makes a lot of sense. It is under discussion for pip as well.

[Spectre5]

Ya, I don't understand how library authors are not clamoring for this. If you put a minimum version in your dependency, it makes 100% sense to test with that version in case you accidentally use a feature from a newer version of it. Then you can decide to bump the dependency version or re-work your code to maintain that older compatibility. I've seen this happen on multiple projects and each would have been saved by testing against the minimum version dependencies.