As written, it seemed to prioritize the older section notation without
clarifying that the older syntax still works but shouldn't be used. This
reorder visually prioritizes the preferred syntax as of 1.2.x while
clearly explaining what the old syntax is during this transition period.

The best next step here would be clearly defining the version in which
dev-dependencies will disappear.

Co-authored-by: Mathieu Kniewallner <mathieu.kniewallner@gmail.com>

Co-authored-by: Randy Döring <30527984+radoering@users.noreply.github.com>

# Pull Request Check List

Resolves: #issue-number-here

<!-- This is just a reminder about the most common mistakes. Please make
sure that you tick all *appropriate* boxes. But please read our
[contribution guide](https://python-poetry.org/docs/contributing/) at
least once, it will save you unnecessary review cycles! -->

- [ ] Added **tests** for changed code.
- [x] Updated **documentation** for changed code.

<!-- If you have *any* questions to *any* of the points above, just
**submit and ask**! This checklist is here to *help* you, not to deter
you from contributing! -->

Co-authored-by: Mathieu Kniewallner <mathieu.kniewallner@gmail.com>

Found some cases where tests were writing to the Poetry test runtime
environment rather than a mocked local directory. This is an issue,
since it meant that some tests were technically stateful when rerunning
locally.

Added in placeholders for those tests. Tested that this succeeds by
using a build where my Poetry venv was made entirely read-only.

https://github.com/python-poetry/poetry/actions/runs/3371708936 shows
that `set-output` is now deprecated.
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
shows the new way of exporting outputs.

We discovered that in some unknown situations, `distribution.files` can
be `None`, causing the assertion to fail. To handle `distribution.files`
being `None` more gracefully, we treat it as if it were an empty list.

Resolves: #6788 

At #5868, I
[suggested](https://github.com/python-poetry/poetry/pull/5868#discussion_r931507885)
that some of the caching that was being reworked could be removed
altogether, because cachecontrol was already taking care of it just
fine.

But now I find myself using an Azure artifacts repository, and it is
returning headers that insist that the client does not do any caching:
```
cache-control: no-cache
pragma: no-cache           
x-cache: CONFIG_NOCACHE 
```
(pypi, by contrast, sets max-age to 10 minutes here).

So I was wrong! And now I am seeing a big performance hit in some
projects where the solve involves overrides and backtracking: and
therefore hitting the legacy simple API repeatedly.

However, we don't need all the mechanism of cachy and its like for this,
a well-placed `@lru_cache()` seems more than sufficient.

This makes me wonder whether it wouldn't be better to do similar for
pypi anyway, and rip out cachecontrol altogether. But let's keep it
simple for now: this is an easy fix to a performance regression.

This avoids trashing connections just to immediately re-create them when
`num-worker` > 10. This should provide a pretty solid speedup on beefy
machines.

I'm not attaching any tests because this would be hard to test and if it
doesn't crash with an unknown keyword argument or something it means
it's probably going to be doing what we expect.

updates:
- [github.com/asottile/pyupgrade: v3.1.0 → v3.2.0](https://github.com/asottile/pyupgrade/compare/v3.1.0...v3.2.0)

requests-toolbelt has released 0.10.0 and 0.10.1 recently. These don't
look to make any backwards-incompatible changes (they only add features)
so poetry should be able to work with them fine.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

# Pull Request Check List

Resolves: #6922

- [-] Added **tests** for changed code.
- [-] Updated **documentation** for changed code.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

required for python-poetry/poetry-core#510

Co-authored-by: Randy Döring <30527984+radoering@users.noreply.github.com>

As in title, switching Python 3.11 in CI from beta to full release

recent flake8-type-checking encourages cast() using the name of the
class rather than the actual class, presumably with the aim that you
might find more things you don't need to import at runtime

however here, consistent with other recent MRs, I've taken the view that
it's better to assert that you have the expected type than to trust that
it's so

`__getattr__` can be cute and all, but it's unhelpful for typechecking
(and human code readers): suddenly any attribute on an object might be
valid, and might return any type at all.

mypy and the unit tests agree that no use is made of the `__getattr__`
on `SitePackages` anyway, so removing it is simply making it clear that
there is no magic.

Co-authored-by: Bartosz Sokorski <b.sokorski@gmail.com>

Updated the outdated copyright year to the present. 
So there will not be a need for any further license year updates

Resolves: #6722

When Renovate bot creates an automated pull request to update Poetry, it
can automatically include the link to changelog so it's easier to find
out what changed.

The URL name has to be one of: 'changelog', 'change log', 'changes',
'release notes', 'news', "what's new" (case insensitive)


https://github.com/renovatebot/renovate/blob/c3a87b687ed44a1a100e0e4f91b81e22b7c32482/lib/modules/datasource/pypi/index.ts#L130-L140

Co-authored-by: Bjorn Neergaard <bjorn@neersighted.com>

also fix formatting for some older entries

updates:
- [github.com/asottile/pyupgrade: v2.38.2 → v3.1.0](https://github.com/asottile/pyupgrade/compare/v2.38.2...v3.1.0)
- [github.com/psf/black: 22.8.0 → 22.10.0](https://github.com/psf/black/compare/22.8.0...22.10.0)

After having created a lock file 2.0, running `poetry lock` with poetry
1.2.1 results in the following output:

```
The lock file is not compatible with the current version of Poetry.
Upgrade Poetry to be able to read the lock file or, alternatively, regenerate the lock file with the `poetry lock` command.
```

Ironically, the error message proposes to run `poetry lock` which
results in this error message.

Further, it doesn't make sense that `poetry lock` fails because it
creates a new lock file from scratch (in contrast to `poetry lock
--no-update`).

Running `poetry lock` is now also possible if there is a broken lock file.

Resolves: #1196