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

Surprising behaviour (and missing warning?) with overlaping python versions #5066

Closed
3 tasks done
DMRobertson opened this issue Jan 19, 2022 · 1 comment · Fixed by #7257
Closed
3 tasks done

Surprising behaviour (and missing warning?) with overlaping python versions #5066

DMRobertson opened this issue Jan 19, 2022 · 1 comment · Fixed by #7257
Labels
area/solver Related to the dependency resolver kind/bug Something isn't working as expected status/confirmed Issue is reproduced and confirmed

Comments

@DMRobertson
Copy link

  • 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).

  • OS version and name: Linux, Fedora 35

  • Poetry version: $ poetry --version
    Poetry version 1.1.12

  • Link of a Gist with the contents of your pyproject.toml file:

Issue

When experimenting with how poetry lock files handle different python versions, I tried poetry installing from the following pyproject.toml.

[tool.poetry]
name = "example-poetry"
version = "0.1.0"
description = ""
authors = ["David Robertson <david.m.robertson1@gmail.com>"]

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

[tool.poetry.dev-dependencies]
pytest = "^5.2"
pillow = [
	{ version = "^9", python = "^3.9" },
	{ version = "^7", python = "^3.7" },
]

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

I hadn't noticed that the project was scoped to python ^= 3.10. Running this on Python 3.10, I expected the constraing python ^3.9 to beat python ^3.7, and so expected poetry to select pillow ^9 at install time. What I saw instead was that poetry reported installing two copies of pillow:

$ poetry install
Creating virtualenv example-poetry-ZY5Szwk5-py3.10 in /home/dmr/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies... (1.5s)

Writing lock file

Package operations: 10 installs, 0 updates, 0 removals

  • Installing pyparsing (3.0.6)
  • Installing attrs (21.4.0)
  • Installing more-itertools (8.12.0)
  • Installing packaging (21.3)
  • Installing pluggy (0.13.1)
  • Installing py (1.11.0)
  • Installing wcwidth (0.2.5)
  • Installing pillow (7.2.0)
  • Installing pillow (9.0.0)
  • Installing pytest (5.4.3)

Installing the current project: example-poetry (0.1.0)

The poetry 7.2.0 installation finished second (is this racey?). If I ask pillow what version is installed, it thinks 7.2:

$ poetry show pillow
name         : pillow
version      : 7.2.0
description  : Python Imaging Library (Fork)

If I ask pip, I get a different answer!!

 $ poetry run pip show pillow
Name: Pillow
Version: 9.0.0
Summary: Python Imaging Library (Fork)
Home-page: https://python-pillow.org
Author: Alex Clark (PIL Fork Author)
Author-email: aclark@python-pillow.org
License: HPND
Location: /home/dmr/.cache/pypoetry/virtualenvs/example-poetry-ZY5Szwk5-py3.10/lib64/python3.10/site-packages
Requires: 
Required-by: 

Confusingly, poetry show --tree includes both versions:

 $ poetry show --tree
pillow 7.2.0 Python Imaging Library (Fork)
pillow 9.0.0 Python Imaging Library (Fork)
pytest 5.4.3 pytest: simple powerful testing with Python
├── atomicwrites >=1.0
├── attrs >=17.4.0
├── colorama *
├── more-itertools >=4.0.0
├── packaging *
│   └── pyparsing >=2.0.2,<3.0.5 || >3.0.5 
├── pluggy >=0.12,<1.0
├── py >=1.5.0
└── wcwidth *

While I don't think I'm using poetry as intended, it'd be nice to avoid falling into this unusual situation is possible. Perhaps the tool could require that the python versions specified for a particular package are pairwise exclusive; i.e. that at most one rule applies to any given python version.

@DMRobertson DMRobertson added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Jan 19, 2022
@finswimmer finswimmer added area/solver Related to the dependency resolver status/confirmed Issue is reproduced and confirmed labels Oct 22, 2022
@radoering radoering removed the status/triage This issue needs to be triaged label Jun 4, 2023
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/solver Related to the dependency resolver kind/bug Something isn't working as expected status/confirmed Issue is reproduced and confirmed
Projects
None yet
3 participants