1.2.0 Release

[abn]

Trying to gather the list of actual blockers for 1.2.0 final release. If there is a PR open that absolutely must be included in the 1.2.0 release, please link them here. Issues, unless they are deemed critical (ie. regression that fundamentally breaks workflows), are unlikely to be considered at this stage.

A link and a short note on why you think is important would suffice. If you agree that a linked issue/pr in the comments is important use 👍 else use 👎 to vote.

Let's avoid bike shedding in here so that the maintainers can focus on the signal.

Blockers

These are a subset of the 1.2 Milestone.

• Release 1.1.0b1 poetry-core#348
• update poetry-core to 1.1.0b1 #5673
• replace poetry plugin commands with more generic poetry self commands #5450
• improve git http authentication via repository configuration #5581
• Poetry tries to remove setuptools and then complains it can't find it #4242
• Release 1.0.2 poetry-plugin-export#56
• Rename implicit group "default" to "main" (poetry-plugin-export version bump) #5587
• ensure setup.py editable builds do not use pep517 #5590
• Remove mentions of Python 2.7 from docs #6234
• union of multi-markers is broken #5593
• Cache clear fails without waiting for input #5633
• Remove tomlkit regression mitigation #5675
• Current master falls back to PyPi when using private repo. #5682
• AttributeError when adding a dependency group when private repo present (Poetry 1.2.0a2) #4718
• Support for multiple-constraint direct origin dependencies with same version #5715
• poetry add "requests[security]" fails on Poetry 1.2.0b1 #5727
• Release 1.2.0b2 #5725
• Unable to create Virtual Environment with MS Store Python #5331
• poetry 1.2.0b3 lock fails with no output #6054
• Locked hash of VCS dependency with extras is ignored when installing #6184

Nice to haves

• Fix for url zip subdirectories #5811
• Fix for git subdirectories #5172
• add progress to download_file if in Indicator context #5451
• add prefetching of index in PEP503 repositories #5442
• build.script: use build environment for execution #5401
• Prefer compatible wheels over source distribution for legacy repository dependency resolution #5385
• Ensure --dry-run option doesn't update poetry.lock for add, update and remove #5718
• Add support for yanked releases and files (PEP-592) #5841
• Use dulwich to fetch global and local git config #5935

General Notes

PEP 610 Changes

Due to changes required in #5362, when upgrading from Poetry 1.1 releases, existings environments might see the following "no update" logs. This is because, with 1.2.0a1, we fixed an issue with the executor that wrote incorrect PEP 610 metadata.

  • Updating tox (3.25.0 /home/abn/.cache/pypoetry/artifacts/a2/33/48/b1983b149095eaa5fbb5f0d48841785f6778b0b3fcb8be53a7506b349a/tox-3.25.0-py2.py3-none-any.whl -> 3.25.0)
  • Updating types-requests (2.27.29 /home/abn/.cache/pypoetry/artifacts/bd/20/0d/db608c01e91c5a34cdf7f8ac0407dde334f95d16c83985b870b17f508f/types_requests-2.27.29-py3-none-any.whl -> 2.27.29)

[neersighted]

I would like to get #5479 or a successor in -- I have yet to look closely to validate the approach, but I think a 1.2 release should solve the underlying issue (#4678), and the root cause shouldn't be too gory.

[matteosantama]

#4979 was deemed a duplicate and closed, but it is different in that it represents a 1.1.x -> 1.2.x regression. As far as I can tell, build scripts will be broken by 1.2.0

[Secrus]

I'd say this: #5529, as big update like this, is good moment to remove 2.7 support. Still working on it though.

[Secrus]

#5633 this should be fixed before release

[mkniewallner]

#3767 may be really nice to have too.

[fsgnil]

Hey folks,

My company is very interested in using poetry as part of our python infrastructure. We have been trying poetry internally and feeling really good about it. The problem is that we need to use poetry plugin to support some of our internal pypi set up. So I'm wondering if there is an estimated release date for poetry 1.2.0.

Thanks!

[neersighted]

Hey folks,

My company is very interested in using poetry as part of our python infrastructure. We have been trying poetry internally and feeling really good about it. The problem is that we need to use poetry plugin to support some of our internal pypi set up. So I'm wondering if there is an estimated release date for poetry 1.2.0.

Thanks!

As with most solely voulenteer-driven projects, the answer is unfortunately when it's ready. The 1.2 release is quite big due to our poor release cadence, so this is taking a decent amount of time to cook. We hope to have a RC out in a week or two, and have a final release a week after that. Setbacks like major regressions or complications in the final few blockers may affect that timeline.

If you are interested in helping us get over the finish line, we're always looking for additional help. I'd suggest joining our Discord server and asking if there's anything you can help with in #contributing -- in particular, we're still looking for more volunteers for triage, as well as product/release management.

[fsgnil]

Thanks for the quick reply.

I'll see if I can contribute too.

[ghost]

Hi there, absolutely love poetry. Would it imply a lot of extra work (wasted volunteer time) to release more beta's while the final release is still blocked? There are several fixes in the master branch which are not in 1.2.0b1, so to use those I would have to install poetry from source, rather than using the install script with --preview.

[abn]

@wvzytlyn we do plan on releasing a new beta this week (hopefully). The short answer to your question is, right now it does still take effort to get a new beta out because we need some manual work (changelogs, testing etc).

While releasing often might be good, right now due to the amount of folks using 1.2.0b1 in production workflows, it might pose a larger issue if we release with known breakages.

Let's keep this issue clear of such discussions. Feel free to ping us on discord or raise discussion on GH.

[yodaldevoid]

As get-poetry.py is getting depreciated with 1.2.0, I'd ask that #5331 be added as a blocker as currently some people are unable to install poetry on Windows with the new installer.

[Darsstar]

I would like to see #5727 fixed. I posted working code in the issue, so now I get to dive in the test cases for solving in order to be a good open source citizen and provide a failing test case.

[neersighted]

As get-poetry.py is getting depreciated with 1.2.0, I'd ask that #5331 be added as a blocker as currently some people are unable to install poetry on Windows with the new installer.

See my comments on that issue -- I don't think we're going to call this a blocker, but I would like to see MS Store Python working before we ship 1.2 if it's not going to hold up the whole release. The issue likely lies in the installer which means it can be fixed after release with no additional patch, anyway.

[yodaldevoid]

As get-poetry.py is getting depreciated with 1.2.0, I'd ask that #5331 be added as a blocker as currently some people are unable to install poetry on Windows with the new installer.

See my comments on that issue -- I don't think we're going to call this a blocker, but I would like to see MS Store Python working before we ship 1.2 if it's not going to hold up the whole release. The issue likely lies in the installer which means it can be fixed after release with no additional patch, anyway.

Fair enough. Thank you for taking a look.

[ashnair1]

Could #5811 be added in the nice to haves?

[fredrikaverpil]

@abn I would like to ad #5935 to this list as 1.1.13 is working fine but without the change in that PR, 1.2 is unusable for me in my private org's GHA where global git config needs to read.

[dimbleby]

Some desirable fixes that are currently on the backlog below.

Having said which: I would personally be happy to see 1.2.0 cut right now, if we can improve the release cadence - things that don't make 1.2.0 can always go into 1.2.x

If there are issues that would help to make the release process faster / easier / more regular: suggest that advertising them prominently in this repository so that folk can chip in and help would be a good move.

Anyway these I think just want someone to hit the merge button

• Use locally cached wheels during install #5871
• don't flush() on every write() cleo#165
• Always show something when rendering exceptions cleo#166

This needs a poetry-core release but looks like a good correctness fix

• solver: fix special case where a direct origin dependency without extras ... #5770

And I have a couple of fixes relating to the correctness of export which require not only a poetry-core release but also some sort of coordination (because CI mess) with poetry-plugin-export:

• Fix complicated export case #5711
• don't export unwanted extras #5819

[johnthagen]

As someone who interacts with Python novices a lot and introduces them to Poetry, I would ask for the following to be considered for 1.2:

• Why does new `install.python-poetry.org` script not add `poetry` to `PATH`? #5917
• [Doc] Add PowerShell snippet in the installation instructions (web & scripts) to allow Windows users to modify %PATH% easier install.python-poetry.org#66

I think that once the new installer becomes default on the website, most users will start using it. The new installer does not add poetry to the PATH automatically. While this might sound trivial to those of us experienced, for novice Windows users this could be a big enough paper cut that they don't continue trying out Poetry (I have witnessed this kind of thing first hand).

Two paths forward I see:

• If it's intentional that Poetry does not want to support adding poetry to the PATH automatically, consider [Doc] Add PowerShell snippet in the installation instructions (web & scripts) to allow Windows users to modify %PATH% easier install.python-poetry.org#66 or similar as a minimal step to help new users quickly get the PATH fixed up
• Restore support to the new installer for adding poetry to the PATH automatically to smooth onboarding new users

[neersighted]

As someone who interacts with Python novices a lot and introduces them to Poetry, I would ask for the following to be considered for 1.2:

* [Why does new `install.python-poetry.org` script not add `poetry` to `PATH`? #5917](https://github.com/python-poetry/poetry/discussions/5917)

* [[Doc] Add PowerShell snippet in the installation instructions (web & scripts) to allow Windows users to modify `%PATH%` easier python-poetry/install.python-poetry.org#66](https://github.com/python-poetry/install.python-poetry.org/issues/66)

I think that once the new installer becomes default on the website, most users will start using it. The new installer does not add poetry to the PATH automatically. While this might sound trivial to those of us experienced, for novice Windows users this could be a big enough paper cut that they don't continue trying out Poetry (I have witnessed this kind of thing first hand).

Two paths forward I see:

* If it's intentional that Poetry does not want to support adding `poetry` to the `PATH` automatically, consider [[Doc] Add PowerShell snippet in the installation instructions (web & scripts) to allow Windows users to modify `%PATH%` easier python-poetry/install.python-poetry.org#66](https://github.com/python-poetry/install.python-poetry.org/issues/66) or similar as a minimal step to help new users quickly get the `PATH` fixed up

* Restore support to the new installer for adding `poetry` to the `PATH` automatically to smooth onboarding new users

See my answer at your linked discussion question -- in short, I don't mind adding a snippet, though I think a 'copy and paste' Powershell snippet is somewhat problematic as not all Windows users use Powershell. In general, as Poetry is a CLI program we do expect users to have enough wherewithall to Google how to modify their PATH -- on Windows it's a well-documented/known GUI.

[neersighted]

New regression/blocker for 1.2: #6054

[dimbleby]

All the blockers are closed. Ship it!

Really: is there anything blocking the release, or is it "just" (yes I know) a question of maintainer time?

• If there is some blocking issue or issues, please share, perhaps someone will want to take it / them on
• If the bottleneck is maintainer time: is there anything the rest of us can do to help?

[neersighted]

Added a new blocker that was just discovered -- there is already a PR pending, we are just waiting on tests.

[Kobold]

You folks are awesome. Thank you for the update @neersighted. I can't say how excited I am for the 1.2 release.

[strangemonad]

I've been running 1.2.0b3. is there anything else we can do to help test for the release?

[radoering]

1.2.0rc1 is just around the corner (#6175). Testing it for regressions is welcome. If there are no major issues, the release should follow shortly after.

[neersighted]

1.2.0rc1 is tagged and is in the stabilization phase. The 1.2 branch is created and will be accepting backports for any last-minute issues found with the release candidate. Assuming we don't have any regressions, 1.2.0 will be released next Monday.

[neersighted]

A quick status update for those following this issue: We had to release 1.2.0rc2 with some important fixes plus the reintroduction of a removed plugin API. We are shooting for this Wednesday for the final release of 1.2.

The related PRs are:

• Add Poetry 1.2.0 announcement website#68 (blog)
• release: bump to version 1.1.0 poetry-core#455 (poetry-core)
• release: bump to version 1.2.0 #6260 (Poetry)

[xylar]

We are unlikely to be able to support poetry 1.2.0 on conda-forge unless #5980 gets figured out. conda fundamentally cannot handle circular dependencies.

[neersighted]

We are unlikely to be able to support poetry 1.2.0 on conda-forge unless #5980 gets figured out. conda fundamentally cannot handle circular dependencies.

This is known and we do not plan to address it as part of 1.2. We have discussed a path for breaking the circular dependency in a way that is compatible with conda-forge and a pleasant user experience, which will start in 1.3 and likely be finalized in 1.4.

Please don't let the version numbers scare you, the intention is to release early and often and to minimize the number of backports to help keep project velocity up. 1.2 is something of an aberration but we have a revitalized core team and much more momentum (plus, no pandemic disrupting people's lives).

[xylar]

@neersighted, okay, thanks. We're already running into packages that can't be built on conda-forge because of not supporting 1.2.0 prereleases so it's good to know that this problem hopefully won't be long lived.

[BradenM]

🚀 Thank you all for the hard work!

[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.