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

poetry lock/export wrong with sys_platform (works fine on ver 1.0.10) #3112

Closed
2 of 3 tasks
mozartilize opened this issue Oct 7, 2020 · 7 comments
Closed
2 of 3 tasks
Labels
kind/bug Something isn't working as expected

Comments

@mozartilize
Copy link

mozartilize commented Oct 7, 2020

  • 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: Ubuntu 20.04
  • Poetry version: 1.1.2 & 1.0.10
  • pyproject.toml
[tool.poetry]
name = "testpoetry-pywin32"
version = "0.1.0"
description = ""
authors = []

[tool.poetry.dependencies]
python = "~3.8"
azureml-widgets = "1.15.0"
azureml-dataset-runtime = "^1.15.0"

[tool.poetry.dev-dependencies]

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

Issue

run poetry lock then poetry export --without-hashes

version 1.0.10

pywin32==228; sys_platform == "win32" and python_version >= "3.6" or platform_system == "Windows" or sys_platform == "win32"

version 1.1.0 & above

pywin32==228
pywin32==228; platform_system == "Windows"
pywin32==228; sys_platform == "win32"
@mozartilize mozartilize added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Oct 7, 2020
abn added a commit to abn/poetry that referenced this issue Oct 9, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112
@abn
Copy link
Member

abn commented Oct 9, 2020

Can you please try the fix at #3119.

Using pipx

pipx install --suffix=@3119 'poetry @ git+https://github.com/python-poetry/poetry.git@refs/pull/3119/head'

Using a container (podman | docker)

podman run --rm -i --entrypoint bash python:3.8 <<EOF
set -e
python -m pip install -q git+https://github.com/python-poetry/poetry.git@refs/pull/3119/head
python -m poetry new foobar
pushd foobar
sed -i /pytest/d pyproject.toml
python -m poetry add --python '~3.8' azureml-widgets@1.15.0 azureml-dataset-runtime@^1.15.0
python -m poetry lock
python -m poetry export --without-hashes | grep pywin32
EOF

This hould output the following.

pywin32==228; sys_platform == "win32" and python_version >= "3.8" and python_version < "3.9" and platform_system == "Windows"

abn added a commit to abn/poetry that referenced this issue Oct 9, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112
@mozartilize
Copy link
Author

@abn Hi, I can confirm that the fix works!

abn added a commit to abn/poetry that referenced this issue Oct 12, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112 #3160
abn added a commit to abn/poetry that referenced this issue Oct 13, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112 #3160
abn added a commit to abn/poetry that referenced this issue Oct 13, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112 #3160
abn added a commit that referenced this issue Oct 14, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: #3112 #3160
abn added a commit to abn/poetry that referenced this issue Oct 14, 2020
This change ensures that markers are propagated from top level
dependencies to the deepest level by walking top to bottom instead of
iterating over all available packages.

In addition, we also compress any dependencies with the same name and
constraint to provide a more concise representation.

Resolves: python-poetry#3112 #3160
(cherry picked from commit e78a67b)
@kichik
Copy link

kichik commented Feb 5, 2021

I am still able to reproduce this issue with Poetry 1.1.4. I used the following pyproject.toml on both Windows and in the python:3.7 Docker image. After locking I can see the right data in poetry.lock. But when exporting all of a sudden it removes the platform limitations.

[tool.poetry]
name = "testpoetry-pywin32"
version = "0.1.0"
description = ""
authors = []

[tool.poetry.dependencies]
python = "~3.7"
azure-identity = "^1.5.0"

[tool.poetry.dev-dependencies]

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

And this is the export result:

$ poetry export | grep pywin32
pywin32==300 \

If I revert to Poetry 1.1.3, it works fine.

@radiophysicist
Copy link

radiophysicist commented Aug 18, 2021

The same on version 1.1.7 in docker (but not reproduced on bare linux host)

@elben10
Copy link

elben10 commented Dec 3, 2021

Any news on this issue?

@matan129
Copy link

matan129 commented Jan 12, 2022

Looks like this is resolved in 1.1.12 by #4686

@abn abn removed the status/triage This issue needs to be triaged label Mar 3, 2022
Copy link

github-actions bot commented Mar 2, 2024

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 Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working as expected
Projects
None yet
Development

No branches or pull requests

6 participants