poetry: Breaking changes to poetry install?

In general, is there a reason that a specific release of poetry is not tied to a specific release of poetry-core?

Typically we restrict to a minor version of poetry-core as we do not normally expect things to break between pre-releases. In this case from 1.1.0a7 to 1.1.0b1 of poetry-core. This is usually sufficient restriction. As far as I can tell most of the issues reported were either misfeatures or outright bugs in 1.2.0b1 which were fixed after the release either via changes in Poetry or poetry-core. Note that this is a new minor for core and poetry simultaneously.

This caught us off guard as well. There seems to be a gap in our test matrix that does not ensure that an upcoming release of poetry-core does not break a previously released version of Poetry. We only test the current master for Poetry.

All that said, I suspect in the future, we might restrict core version a bit further, atleast prior to a stable release.

but it’s hard to justify using poetry for a production system if we could wake up any morning and find CI is suddenly failing even though no code or dependencies changed on our end.

The frustration is understandable. I suspect part of the issue here is that the 1.2.0 release has been piling on fixes and features forcing the community to use a prerelease in production environments. I am hopeful that once the 1.2.0 release is done we should be able to get new fixes out with better cadence. This should aleaviate the risk of relying on unstable and prone to breaking releases.

For environments that need a higher degree of confidence, I would even recommend that a constraints file be used when installing poetry. Hopefully though, this is merely a transitional issue.

The issue has to do with Poetry’s runtime environment. When you install using the script, a venv is created and poetry is installed via pip. Since poetry 1.2.0b1 says Requires-Dist: poetry-core>=1.1.0a7 the latest beta gets installed.

A quick way to downgrade core is to execute this. Note this is only tested for linux environments.

${POETRY_HOME:-${XDG_DATA_HOME:-~/.local/share}}/pypoetry/venv/bin/python -m pip install --force --no-deps poetry-core==1.1.0a7

Ref: https://github.com/python-poetry/install.python-poetry.org/blob/0fab38103455fdb6d630f25ce0d4ccb11f90f9cb/install-poetry.py#L6-L14

Hi @abn, thanks for the reply and the explanation.

In general, is there a reason that a specific release of poetry is not tied to a specific release of poetry-core? I just made an internal push for my organization to move our build to poetry, but it’s hard to justify using poetry for a production system if we could wake up any morning and find CI is suddenly failing even though no code or dependencies changed on our end.

The issue has to do with Poetry’s runtime environment. When you install using the script, a venv is created and poetry is installed via pip. Since poetry 1.2.0b1 says Requires-Dist: poetry-core>=1.1.0a7 the latest beta of poetry core gets installed.

A quick way to downgrade core is to execute this. Note this is only tested for linux environments.

${POETRY_HOME:-${XDG_DATA_HOME:-~/.local/share}}/pypoetry/venv/bin/python -m pip install --force --no-deps poetry-core==1.1.0a7

Ref: https://github.com/python-poetry/install.python-poetry.org/blob/0fab38103455fdb6d630f25ce0d4ccb11f90f9cb/install-poetry.py#L6-L14

@abn @radoering thank you again for being so quick to respond and thorough in your explanations / assistance!

@gavrieladler Can you please check if you get the [BUG] torchvision (0.9.2+cu111 url) is not satisfied. when using poetry master? If you get the error, please create a separate issue with a complete pyproject.toml to reproduce it. Otherwise that may go under because it seems not related to the original “trailing comma issue” and I’m not sure if it is only with poetry 1.2.0b1 + poetry-core 1.1.0b1 or if it still exists in master.

I just confirmed that the issue is resolved when using master.

Hi, we are also experiencing production issues that started yesterday evening (EST). In our pyproject.toml we have:

[tool.poetry.dependencies]
torchvision = { url = "https://download.pytorch.org/whl/lts/1.8/cu111/torchvision-0.9.2%2Bcu111-cp38-cp38-linux_x86_64.whl" }

We have been installing this package on poetry 1.2.0b1 for a few months in CI with no issues, but as of last night we now see:

 Installing dependencies from lock file

  RuntimeError

  [BUG] torchvision (0.9.2+cu111 url) is not satisfied.

  at ~/.local/share/pypoetry/venv/lib/python3.8/site-packages/poetry/mixology/partial_solution.py:204 in satisfier
      200│             # As soon as we have enough assignments to satisfy term, return them.
      201│             if assigned_term.satisfies(term):
      202│                 return assignment
      203│ 
    → 204│         raise RuntimeError(f"[BUG] {term} is not satisfied.")
      205│ 
      206│     def satisfies(self, term: Term) -> bool:
      207│         return self.relation(term) == SetRelation.SUBSET
      208│ 
Error: Process completed with exit code 1.

Each CI run installs poetry fresh via curl -sSL https://install.python-poetry.org/ | python3 - --version 1.2.0b1, so we also believe somehow the release has changed out from under us. How do we get this rolled back? Thanks!

Do you have a rough ETA on the 1.2.0 release?

The current plan is to have another beta (~1 week), followed by an rc then stable release.

In general, is there a reason that a specific release of poetry is not tied to a specific release of poetry-core?

Typically we restrict to a minor version of poetry-core as we do not normally expect things to break between pre-releases. In this case from 1.1.0a7 to 1.1.0b1 of poetry-core. This is usually sufficient restriction. As far as I can tell most of the issues reported were either misfeatures or outright bugs in 1.2.0b1 which were fixed after the release either via changes in Poetry or poetry-core. Note that this is a new minor for core and poetry simultaneously.

This caught us off guard as well. There seems to be a gap in our test matrix that does not ensure that an upcoming release of poetry-core does not break a previously released version of Poetry. We only test the current master for Poetry.

All that said, I suspect in the future, we might restrict core version a bit further, atleast prior to a stable release.

but it’s hard to justify using poetry for a production system if we could wake up any morning and find CI is suddenly failing even though no code or dependencies changed on our end.

The frustration is understandable. I suspect part of the issue here is that the 1.2.0 release has been piling on fixes and features forcing the community to use a prerelease in production environments. I am hopeful that once the 1.2.0 release is done we should be able to get new fixes out with better cadence. This should aleaviate the risk of relying on unstable and prone to breaking releases.

For environments that need a higher degree of confidence, I would even recommend that a constraints file be used when installing poetry. Hopefully though, this is merely a transitional issue.

Thanks for the detailed explanation, appreciated. Do you have a rough ETA on the 1.2.0 release?

Hi, we are also experiencing production issues that started yesterday evening (EST). In our pyproject.toml we have:

@gavrieladler the downgrade suggested about should mitigate your solver issue. But, I would also recommend that you test out the latest change in master for your project as that might have a fix that works with the latest poetry-core beta.

curl -sSL https://install.python-poetry.org | python3 - --git https://github.com/python-poetry/poetry.git@master

@gavrieladler Can you please check if you get the [BUG] torchvision (0.9.2+cu111 url) is not satisfied. when using poetry master? If you get the error, please create a separate issue with a complete pyproject.toml to reproduce it. Otherwise that may go under because it seems not related to the original “trailing comma issue” and I’m not sure if it is only with poetry 1.2.0b1 + poetry-core 1.1.0b1 or if it still exists in master.