Repository navigation
Poetry doesn't install extra dependencies when the extra is capitalised #6321
Description
-
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 (
-vvvoption). -
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
Activity
dimbleby commentedon 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 commentedon 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 commentedon Sep 2, 2022
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 existingpyproject.toml.dimbleby commentedon Sep 16, 2022
PEP685 is accepted and declares that:
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.github-actions commentedon 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.