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 doesn't install extra dependencies when the extra is capitalised #6321

Closed
3 tasks done
bacon1664 opened this issue Sep 1, 2022 · 5 comments · Fixed by python-poetry/poetry-core#476
Closed
3 tasks done
Labels
area/deps Related to representing and locking dependencies kind/bug Something isn't working as expected

Comments

@bacon1664
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).

  • Arch Linux x86_64 and python 3.7.9:

  • Poetry version 1.2.0:

  • I cannot disclose the contents of my pyproject file.

Issue

We have a sub-project which defines extras with a capital like so:

[tool.poetry]
name="foo"
version="1.0.0"

[tool.poetry.dependencies]
XlsxWriter = { version = "^1.2.8", optional = true }

[tool.poetry.extras]
XlsxWriter = ["XlsxWriter"]

When attempting to install this sub-project as a dependency as follows:

[tool.poetry.dependencies]
foo = {extras = ["XlsxWriter"], version="1.0.0"}

The optional dependency (XlsxWriter here) is not installed at all.

If the dependency's extra name is updated to be in low-case only like so:

[tool.poetry.extras]
xlsxwriter = ["XlsxWriter"]

And the dependent's definition is updated to match:

[tool.poetry.dependencies]
foo = {extras = ["xlsxwriter"], version="1.0.0"}

Then the optional dependency now gets installed by poetry 1.2

@bacon1664 bacon1664 added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Sep 1, 2022
@dimbleby
Copy link
Contributor

dimbleby commented Sep 1, 2022

https://github.com/python-poetry/poetry/blob/master/src/poetry/utils/helpers.py#L155-L163

I guess poetry sometimes normalizes extra names and sometimes doesn't.

Hard to get too excited - just use lowercase extras - but if anyone cares to investigate further then the use of safe_extra() looks like the right thread to tug on.

@hanscg
Copy link

hanscg commented Sep 2, 2022

Happened in our project as well.
We have dependency defined like this:pyqrcode = {version = "^1.2", extras = ["PNG"]} and it didn't install the extras.
This worked fine on 1.1.15

@bacon1664
Copy link
Author

I see that this behaviour was introduced by the pull request 4122 in June this year (poetry 1.2.0b3). That PR addressses the issue 4123 where Poetry's behaviour with regards to extras differed from Pip.

I can't say whether the different behaviour observed in 1.2 is in fact correct and the previous behaviour was that I was exploiting a bug. It would make sense to me that safe_extras() also be used to normalise the names of extras specified in the existing pyproject.toml.

@dimbleby
Copy link
Contributor

PEP685 is accepted and declares that:

When comparing extra names, tools MUST normalize the names being compared using the semantics outlined in PEP 503 for names:

so safe_extra() should be removed, canonicalize_name() should be used instead, and indeed the names of extras should be normalized both on the what-is-requested and on the what-is-provided side.

Copy link

github-actions bot commented Mar 1, 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 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/deps Related to representing and locking dependencies kind/bug Something isn't working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants