Allow specifying a different Python version in dev-dependencies

[ghost]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

It would be nice to have an option to require a higher Python version for development than for runtime. For example, I use flake8-type-checking which requires Python 3.8, but I want to support Python 3.7 for my library. For now I can just specify a python = "^3.8" constraint for flake8-type-checking, but then if my dev environment happens to be Python <= 3.7 it will just silently not install that package.

[clintonroy]

I'm thinking dev might not be the right group for this stuff, that a lot of tools should be put into separate virtual environments. It might be something to put into pre-commit configuration, or even a separate project.

[bdusell]

Agreed, I've been running into a similar problem today. I want to make the Python version under dependencies as permissive as possible, but this unnecessarily restricts me from using the latest versions of packages under dev-dependencies, because many new packages drop support for old versions of Python. There's no good reason the Python versions supported by my package should restrict the versions of my dev tools, or vice versa.

[neersighted]

#5740 or a successor is likely the way to go here... Ultimately what you want is for tools that do not interact with your project on a source code level (e.g. tox) to not influence your dep tree, while still allowing for resolution of tools that do interact (e.g. pytest).

I don't think we'll ever add support for multiple Python constraints, as doing so would require a radical re-engineering of Poetry and is (more or less) incompatible with our unified lock file and seamless multi-platform support.

I'm going to close this for now as something that won't be implemented -- however, I think that there is very much an X-Y problem here, and #5740/something like it will solve the issue in question.

[ghost]

Yeah, I do use pre-commit, but until someone makes a proper pre-commit neovim plugin that puts the linter messages in quickfix, I’d still prefer to have my linters installed locally too. Especially when I need to suddenly mass fix a bunch of files. But it’s understandable if this is out of scope for Poetry.

[neersighted]

I think the PR I linked will address that use case -- you would be able to add flake8 and all the plugins for it you want separate from your project, but managed by Poetry, if that was implemented.

[github-actions]

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.