question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Failed to install packages that target a range of python versions if local python version is not fixed

See original GitHub issue
  • I am on the latest Poetry version.
  • I have searched the issues of this repo and believe that this is not a duplicate.
  • If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
▶ poetry debug:info

Poetry
======

 * Version: 0.12.17
 * Python:  3.7.0


Virtualenv
==========

 * Python:         3.7.0
 * Implementation: CPython
 * Path:           /Users/user/projectX/.venv
 * Valid:          True


System
======

 * Platform: darwin
 * OS:       posix
 * Python:   /Users/user/.pyenv/versions/3.7.0

pyproject.toml

[tool.poetry]
name = "projectX"
version = "0.1.0"
description = ""
authors = ["user <user@cie.com>"]

[tool.poetry.dependencies]
python = "^3.7"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Issue

When I try to install a dependency that target a range of python versions, that seems to contains the python version I target in my pyproject.toml it fails with the following error.

▶ poetry add kedro -vvv
Using virtualenv: /Users/user/projectX/.venv
PyPI: 7 packages found for kedro *
Using version ^0.15.1 for kedro

Updating dependencies
Resolving dependencies...
   1: fact: projectX is 0.1.0
   1: derived: projectX
   1: fact: projectX depends on kedro (^0.15.1)
   1: selecting projectX (0.1.0)
   1: derived: kedro (^0.15.1)
PyPI: 1 packages found for kedro >=0.15.1,<0.16.0
   1: fact: kedro (0.15.1) requires Python >=3.5, <3.8
   1: derived: not kedro (0.15.1)
   1: fact: no versions of kedro match >0.15.1,<0.16.0
   1: conflict: no versions of kedro match >0.15.1,<0.16.0
   1: ! kedro (>0.15.1,<0.16.0) is partially satisfied by not kedro (0.15.1)
   1: ! which is caused by "kedro (0.15.1) requires Python >=3.5, <3.8"
   1: ! thus: kedro is forbidden
   1: ! kedro (>=0.15.1,<0.16.0) is satisfied by kedro (^0.15.1)
   1: ! which is caused by "projectX depends on kedro (^0.15.1)"
   1: ! thus: version solving failed
   1: Version solving took 0.037 seconds.
   1: Tried 1 solutions.

[SolverProblemError]
The current project must support the following Python versions: ^3.7
Because no versions of kedro match >0.15.1,<0.16.0
 and kedro (0.15.1) requires Python >=3.5, <3.8, kedro is forbidden.
So, because projectX depends on kedro (^0.15.1), version solving failed.

Exception trace:
 /Users/user/.poetry/lib/poetry/_vendor/py3.7/cleo/application.py in run() at line 94
   status_code = self.do_run(input_, output_)
 /Users/user/.poetry/lib/poetry/console/application.py in do_run() at line 88
   return super(Application, self).do_run(i, o)
 /Users/user/.poetry/lib/poetry/_vendor/py3.7/cleo/application.py in do_run() at line 197
   status_code = command.run(input_, output_)
 /Users/user/.poetry/lib/poetry/console/commands/command.py in run() at line 77
   return super(BaseCommand, self).run(i, o)
 /Users/user/.poetry/lib/poetry/_vendor/py3.7/cleo/commands/base_command.py in run() at line 146
   status_code = self.execute(input_, output_)
 /Users/user/.poetry/lib/poetry/_vendor/py3.7/cleo/commands/command.py in execute() at line 107
   return self.handle()
 /Users/user/.poetry/lib/poetry/console/commands/add.py in handle() at line 139
   status = installer.run()
 /Users/user/.poetry/lib/poetry/installation/installer.py in run() at line 73
   self._do_install(local_repo)
 /Users/user/.poetry/lib/poetry/installation/installer.py in _do_install() at line 165
   ops = solver.solve(use_latest=self._whitelist)
 /Users/user/.poetry/lib/poetry/puzzle/solver.py in solve() at line 38
   packages, depths = self._solve(use_latest=use_latest)
 /Users/user/.poetry/lib/poetry/puzzle/solver.py in _solve() at line 180
   raise SolverProblemError(e)

add [-D|--dev] [--git GIT] [--path PATH] [-E|--extras EXTRAS] [--optional] [--python PYTHON] [--platform PLATFORM] [--allow-prereleases] [--dry-run] [--] <name> (<name>)...

As you can see from the error and from the kedro pypi release page, the target python version is Python >=3.5, <3.8. I specify python ^3.7 in my pyprojet.toml and as you can see when I run poetry debug:info my python version is * Python: 3.7.0 .

Other info, if I change the pyproject.toml:

[tool.poetry.dependencies]
python = "^3.7"

To:

[tool.poetry.dependencies]
python = "3.7"

It’s working

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:42
  • Comments:43 (8 by maintainers)

github_iconTop GitHub Comments

16reactions
finswimmercommented, Apr 28, 2020

Hello,

the “issue” here is one of the most misunderstood of poetry’s version resolving. poetry checks if the versions that are given in the pyproject.toml are always valid and not just with the currently used python version.

So, if one define that the project is compatible with python ^3.6 this means it’s compatible with all python versions >=3.6 but <4.0.

Let’s have a look at one of the examples above:

dataclasses requires Python >=3.6, <3.7

dataclass is not available for python >3.7 here.

Or this one:

[SolverProblemError]
The current project's Python requirement (>=3.7) is not compatible with some of the required packages Python requirement:
  - taskipy requires Python >=3.6,<4.0
  - taskipy requires Python >=3.6,<4.0

The python requirement for the project has no upper boundary but taskipy has.

A further requirement is, that there is one major version of a package that is compatible with all python version. If this is not the case, the cli is not able to resolve this and we have to help by defining the version in the pyproject.toml. See here how this looks like.

fin swimmer

12reactions
sdispatercommented, Jun 1, 2020

@nils-werner I know it might be confusing but there is actually a good and logical reason behind the way Poetry behaves in those cases.

As an example, I will take the taskipy example mentioned by @matthijskooijman:

  • The project declares being compatible with Python >=3.7
  • This project depends on taskipy which declares being compatible only with Python >=3.6,<4.0.
  • So, it means that taskipy would not be satisfied for Python >=4.0 (the difference between >=3.7 and >=3.6,<4.0)

At this point, you have two choices, either change the python requirement of your project to >=3.7,<4.0 (however, note that this is not what I would personally recommend because it would mean changing the declared compatible Python versions to accommodate the dependencies) or specify that the taskipy dependency should only be installed for Python >=3.7,<4.0 by using the python property or the markers property:

taskipy = {version = "^1.2.1", python = ">=3.7,<4.0"}

It will now work properly.

This will be better explained when the 1.1 version of Poetry is released:

Screenshot 2020-06-01 at 12 45 54

On another note

I absolutely get that the Python version should be pinned during deployment, but that’s what poetry.lock does/should do, no?

No, the lock file is system and Python version agnostic.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Install a module using pip for specific python version
On Debian/Ubuntu, pip is the command to use when installing packages for Python 2, while pip3 is the command to use when installing...
Read more >
Visual Studio 2022 Release Notes | Microsoft Learn
Get the latest features, bug fixes, and support for Visual Studio 2022. Download today.
Read more >
Dependency Resolution - pip documentation v22.3.1
Dependency Resolution#. pip is capable of determining and installing the dependencies of packages. The process of determining which version of a dependency ...
Read more >
Basic Usage — Spack 0.20.0.dev0 documentation
If there is no new version for either of the packages, spack install will simply mark them as explicitly installed and spack gc...
Read more >
What's New In Python 3.8 — Python 3.11.1 documentation
Python now uses the same ABI whether it's built in release or debug mode. On Unix, when Python is built in debug mode,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found