poetry icon indicating copy to clipboard operation
poetry copied to clipboard

Specify a different python version for a dependency group

Open spapanik opened this issue 3 years ago • 4 comments

  • [x] I have searched the issues of this repo and believe that this is not a duplicate.
  • [x] I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

I've started using the dependency groups (which are absolutely fantastic). Still, I have reached an issue, that some groups exist only for a particular purpose (eg, to build the documentation, or to lint the project). The issue that I'm facing is that as a library developer, I want to support all supported python versions, so I normally set my python version in something like python = "^3.7.0" (accurate as of 1/1/2023), but not all libraries that are used to build docs/lint the project support every version (eg latest flake8 only supports python>=3.8.1). But for example, flake8 plugins depend on flake8, so I have to either write the same python dependency again and again (and I would prefer not to duplicate that) or wait in order to update (which I currently do, but it seems unnecessary).

spapanik avatar Jan 04 '23 16:01 spapanik

Hello @spapanik,

I think this is a duplicate of #5037.

fin swimmer

finswimmer avatar Jan 04 '23 16:01 finswimmer

I don't think this is a duplicate of 5037. Issue 5037 is about isolating dependencies. This issue is about only applying version constraints when needed.

Here is a motivating example

[tool.poetry]
package-mode=false

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

[tool.poetry.group.docs]
optional=true

[tool.poetry.group.docs.dependencies]
python = ">=3.11"
mkdocs-material = "^9.1.0"
mkdocs-material-extensions = "^1.3.1"
mkdocs-entangled-plugin="0.4.0"

Actual behavior

Executing poetry install --with docs and poetry install -without=docs will result in an error regardless of python version

Resolving dependencies... (0.0s)

The current project's supported Python range (>=3.8,<4.0) is not compatible with some of the required packages Python requirement:
  - mkdocs-entangled-plugin requires Python >=3.11,<4.0, so it will not be satisfied for Python >=3.8,<3.11

Because non-package-mode depends on mkdocs-entangled-plugin (0.4.0) which requires Python >=3.11,<4.0, version solving failed.

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties
    
    For mkdocs-entangled-plugin, a possible solution would be to set the `python` property to ">=3.11,<4.0"

    https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies,
    https://python-poetry.org/docs/dependency-specification/#using-environment-markers

Desired behavior

I expect that poetry install --without docs works for python="^3.8. This ensures users of my library can use whatever version they like.

I expect that poetry install --with docs works for python=^3.11. This allows me to use the latest and greatest tools to build the docs.

ErikDeSmedt avatar Apr 02 '24 13:04 ErikDeSmedt

I would very much like this to be possible.

I have ipython and pydata-sphinx-theme in my dev and docs group respectively, and they require Python 3.10 or higher. But my package works with Python 3.8 or higher. But now my Readthedocs builds are failing unless I require Python 3.10 but I don't want to deprecate 3.8 and 3.9, so I'm stuck.

Not sure what a good work-around is to allow my package to have a more relaxed Python requirement but force other groups to use a newer one.

glentner avatar Apr 18 '24 02:04 glentner

Not sure what a good work-around is to allow my package to have a more relaxed Python requirement but force other groups to use a newer one.

A workaround that I have found to be working is what I do here: https://github.com/spapanik/yamk/blob/32b61d70246/pyproject.toml#L167 I specify the min versions for ipython and the other dev packages, and I pay the penalty that I can develop in python 3.10+ only. But it's an acceptable price to pay IMHO, as the CI should catch any errors.

spapanik avatar May 02 '24 11:05 spapanik