Unable to `poetry install` twisted trunk and treq

• 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).

• OS version and name: Fedora 35
• Poetry version: 1.1.12
• Pyproject.toml:

  [tool.poetry]
  name = "test"
  version = "0.1.0"
  description = ""
  authors = ["David Robertson <[e-mail]>"]
  
  [tool.poetry.dependencies]
  python = "^3.10"
  Twisted = {git = "https://github.com/twisted/twisted.git", branch = "trunk"}
  treq = "^22.2.0"
  
  [tool.poetry.dev-dependencies]
  
  [build-system]
  requires = ["poetry-core>=1.0.0"]
  build-backend = "poetry.core.masonry.api"
  

Issue

I tried to install twisted trunk and treq as follows:

• poetry init
• poetry add git+https://github.com/twisted/twisted.git#trunk
• poetry add treq

Step three tried to install treq ^22.2.0 which is the newest version. This failed: see add treq.txt.

I find the output hard to read (not helped by Twisted’s date-based versioning scheme), but I think what’s happening is:

• treq 22.2.0 requires "Twisted[tls] >= 18.7.0"
• poetry deduces the set of possible twisted versions: Thus, treq (>=22.2.0,<23.0.0) requires twisted (18.7.0 || 18.9.0 || 19.2.0 || 19.2.1 || 19.7.0 || 19.10.0 || 20.3.0 || 21.2.0 || 21.7.0 || 22.1.0 || 22.2.0).
• This doesn’t include include twisted 22.2.0.post0, the trunk version; I’m guessing this isn’t being considered and that’s why resolution fails?

I’ve also tried marking both with allow_prereleases=true but that didn’t seem to change any behaviour—I’m guessing this refers to prereleases on PyPI rather than from-git prereleases.

Am I doing something wrong here?

[callahad]

Workaround works. Suggest we can close this?

[radoering]

The issue is not limited to locked repository (poetry lock --no-update or poetry add with existing lock file). It can be triggered without an existing poetry.lock just by running poetry lock with the given pyproject.toml. #5770 seems to solve all of these use cases.