poetry icon indicating copy to clipboard operation
poetry copied to clipboard

Setting extras as non-optional

Open ClementPinard opened this issue 1 year ago • 2 comments

Issue Kind

Improving documentation

Existing Link

https://python-poetry.org/docs/pyproject/#extras

Description

In the documentation for extra, we can read this :

https://python-poetry.org/docs/pyproject/#extras

[tool.poetry]
name = "awesome"

[tool.poetry.dependencies]
# These packages are mandatory and form the core of this package’s distribution.
mandatory = "^1.0"

# A list of all of the optional dependencies, some of which are included in the
# below `extras`. They can be opted into by apps.
psycopg2 = { version = "^2.9", optional = true }
mysqlclient = { version = "^1.3", optional = true }

[tool.poetry.extras]
mysql = ["mysqlclient"]
pgsql = ["psycopg2"]
databases = ["mysqlclient", "psycopg2"]

My question is, what if we don't want to set these dependencies as optional within the repo ?

[tool.poetry]
name = "awesome"

[tool.poetry.dependencies]
# These packages are mandatory and form the core of this package’s distribution.
mandatory = "^1.0"


psycopg2 = "^2.9"
mysqlclient = "^1.3"

[tool.poetry.extras]
mysql = ["mysqlclient"]
pgsql = ["psycopg2"]
databases = ["mysqlclient", "psycopg2"]

Basically, a poetry install inside the repo would install everything, and poetry add awesome would not install pyscopg2 nor mysqlclient unless a -E option is selected.

This makes sense from a developer point of view to treat extra as dev package to perform e.g. tests or docker build

From my experience, this works the way I thought, and extra without mentioning optional still makes packages optional when installing them from outside.

My question, is this behaviour in some way official ? Can I consider this undocumented feature to be stable ? And if so, would it be interesting to mention is in the docs ?

For me, extras and optional are two different things. I know it will be confusing when there is already some confusion between extras and groups, but I feel like this usage of non-optional extras is legitimate and could be officialized in some way.

ClementPinard avatar Jul 23 '24 15:07 ClementPinard

I expect this will eventually break in confusing ways.

dimbleby avatar Jul 23 '24 18:07 dimbleby

I think this would make more sense if the non-optional, within the current project dependencies are declared in a non-main group, and poetry should assume that if someone declared the dependency within [tool.poetry.extras] but not in the main group (e.g. not in [tool.poetry.dependencies]), then it should assume automatically that the dependency is optional in the built package but mandatory in the current project. For example, like this:

[tool.poetry.dependencies]
non-optional-in-build-dep = "^2.9"

[tool.poetry.group.required-in-project.dependencies]
optional-in-build-dep = "^2.9"

[tool.poetry.extras]
extra-name = ["optional-in-build-dep"]

Currently, poetry just ignores the dependency withing extra-name = ["optional-in-build-dep"] since optional-in-build-dep isn't in the "main" group, and it adds a worthless Provides-Extra: extra-name in the built wheel, so it would be MUCH nicer if poetry saw that it wasn't in "main" but was in another group and treated that build dependency as optional.

ppena-LiveData avatar Nov 20 '24 21:11 ppena-LiveData