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

refresh lockfile

it looks as though the latest lock was done with a cache that is missing
some recent uploads

This handles the TODO for checking the existence of the files being
uploaded by the Uploader class.

https://github.com/python-poetry/poetry/blob/c967a4a5abc6a0edd29c57eca307894f6e1c4f16/poetry/publishing/uploader.py#L229
In the case that a file does not exist, it raises a UploadError.

The raised error message is as follows: `Archive ([FILENAME]) does not exist`

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

Resolves some discussion in #3855

Inspects trove classifiers on `check` CLI command calls, and look for
unrecognized and deprecated categories.

Adds dependency https://github.com/pypa/trove-classifiers, a package
published and maintained by the PyPA that is cataloguing all classifiers.
This is the canonical source of all trove definitions.

Resolves: #2579

Resolves: #2034 

It's useful to both developer tools and for users to recognize the
lock file is generated. This header should achieve both.

Resolves: #6018 

1. Added a check so that if `python` argument is a file (then it should
be a python path) - extract it's venv name and raise `IncorrectEnvError`
if it doesn't belong to this project
    **Before**
    ```
└❯ poetry env remove
~/.cache/pypoetry/virtualenvs/different-project-OKfJHH_5-py3.10/bin/python
    /bin/sh: 1: different-project-OKfJHH_5-py3.10: not found

Deleted virtualenv: ~/.cache/pypoetry/virtualenvs/poetry-4pWfmigs-py3.10
    ```
    Removes current project's env, which is wrong.
    **After**
    ```
└❯ poetry env remove
~/.cache/pypoetry/virtualenvs/different-project-OKfJHH_5-py3.10/bin/python

Env different-project-OKfJHH_5-py3.10 doesn't belong to this project.
    ```
2. Added the exact same check as before ^, but for cases where env name
is passed.
    **Before**
    ```
    └❯ poetry env remove different-project-OKfJHH_5-py3.10      
     /bin/sh: 1: different-project-OKfJHH_5-py3.10: not found

Command different-project-OKfJHH_5-py3.10 -c "import sys;
print('.'.join([str(s) for s in sys.version_info[:3]]))" errored with
the following return code 127, and output:
    ```
Errors while trying to exec env name as an interpreter, error is not
clear.
    **After**
    ```
└❯ poetry env remove different-project-OKfJHH_5-py3.10

Env different-project-OKfJHH_5-py3.10 doesn't belong to this project.
    ```
3. Added a couple of tests for **new** and for **old** scenarios which
weren't tested.
4. Added `venv_name` fixture for `tests/utils` directory to use in
`test_env`. Also replaced some of `"simple-project"` hardcoded value to
use `poetry.package.name`

It's up to maintainers to choose what they want for this project - I'm
happy either way if we at least fix the bug. I can remove/change any of
the stuff I added on top of the fix. But yeah I just decided that if we
fix the bug, we might also make some improvements/changes in this area
of code. Any thoughts on this are welcome, thanks!

Resolves #6076 

I've taken the JSON version of the simple API and converted it into a
`LinkSource` so that the package-finding logic in the `PyPiRepository`
is very similar to - but annoyingly not quite the same as! - the
`LegacyRepository`.

I've also taken the opportunity to refactor the `LegacyRepository` ever
so slightly to emphasise that similarity. I think I've probably fixed a
small bug re caching and pre-releases: previously the processing for
ignored pre-releases was skipped when reading from the cache.

I believe this change will tend to be a modest performance hit. Eg
consider a package like `cryptography`, for which there are maybe a
couple of dozen downloads available at each release: to get the
available versions we now have to iterate over each of those files and
parse their names, rather than simply reading the answer.

However if the API that poetry currently uses is truly deprecated I see
little choice but to suck that up - or risk being in an awkward spot
when it is turned off. cf #5970, but worse.

Most of the changes are in the test fixtures:
- unversioned fixtures were generated from the existing fixtures: I
didn't want to download fresh data and start getting different answers
than the tests were expecting
- new versioned fixtures were downloaded fresh

Relates-to: #4776 

Adding the hook leads to four new warnings for the repo.
-
[PIE803](https://github.com/sbdchd/flake8-pie#pie803-prefer-logging-interpolation):
prefer-logging-interpolation
This check produces false positives (`debug()` calls are always flagged
as if they belong to a logger). PR ignores such instances and fixes the
rest.
-
[PIE786](https://github.com/sbdchd/flake8-pie#pie786-precise-exception-handlers):
precise-exception-handlers
PR ignores instances where the intention is indeed to catch any
exceptions and fixes the rest.
-
[PIE798](https://github.com/sbdchd/flake8-pie#pie798-no-unnecessary-class):
no-unnecessary-class
All instances are ignored via an additional entry in flake8 config.

When you already have a `Version` in hand,
`normalize_version(version.text)` is a very roundabout way of calling
`version.to_string()`: it re-parses the version text to give you the
same `Version` you already had and then calls `to_string()` on that.

https://github.com/python-poetry/poetry-core/blob/37cee90a5dd4c7ee2c5ee836216ba813242b3ade/src/poetry/core/utils/helpers.py#L27-L28

Then calling `escape_version()` on such a version is actually
counter-productive, per #6466.

Similar changes can and should be made over in poetry-core, but it
should be safe to merge this before that is done.

When running `poetry lock`, dependencies with less candidates are chosen first.
Prior to this change when running `poetry update`, all whitelisted dependencies (aka `use_latest`) got the same priority which results in a more or less random resolution order.

Previously, we rely on the `display_name` stored with `tomlkit.Table`,
which is an internal implementation detail, and it breaks
https://github.com/sdispater/tomlkit/pull/234. This PR corrects the
nested table level, because `preserved` map comes from the poetry config
table.

Resolves: #6521

If one poetry installation is writing to the cache while a second
installer is attempting to read that cache file, the second installation
will fail because the in-flight cache file is invalid while it is still
being written to by the first process.

This PR resolves this issue by having Poetry write to a temporary file
in the cache directory first, and then rename the file after it's
written, which is ~atomic.

Resolves: #5142 

I'm not sure how to test this change, as the conditions which cause this
bug to appear are a little hard to reproduce.

Bump to Dulwich 0.20.46.

This version applies applyInsteadOf to rsync-style URLs. Fixes #6329

Added explanation to docs why `pre-commit autoupdate` will not find
latest version for Poetry's hooks.

`--dev` is marked as deprecated for both
[add](https://python-poetry.org/docs/cli/#options-4) and
[remove](https://python-poetry.org/docs/cli/#options-5) commands in the
documentation and emit a warning when used, but this is not reflected in
the CLI help messages.

I also took the occasion to update the documentation to suggest
replacements. Once backported, this would also require an update of the
1.2.0 blog post announcement, which doesn't mention those deprecations.

Refreshing lock file, mostly to pick up
https://github.com/certifi/python-certifi/compare/2022.06.15...2022.06.15.1
that will remove some deprecation warnings raised on Python 3.11, and
pick up wheels for `dulwich` on 3.11.

This PR splits out simple part of #6130. Once this merged I'll update
that PR to contain only second (more controversial) fix.

Another random bit of code-tidying:

- remove some dead code that constructs an unused dictionary
- simplify (considerably) the code that walks the dependency tree looking for packages introduced by extras

I tried to clarify how the `virtualenvs.create` config option works and
why it is a good idea to have virtual environments in docker containers
as well.

Resolves: #6436

Measurements of `poetry lock` with warm cache with example
pyproject.toml from #6436:

|test case|time in s|peak memory usage in MB|
|---|---|---|
|legacy repository (before)|422|113|
|legacy repository (after)|3|118|
|pypi repository|1|92|

`backports.cached-property` is used in order to support
cached_property on Python 3.7. 

Co-authored-by: Jarrod Moore <jmo@jmo.name>
Co-authored-by: Bjorn Neergaard <bjorn@neersighted.com>

Refactor `show` command a tiny bit to separate the different cases into
dedicated functions, since right now `handle` method is 300 lines long.
This also has the advantage of making some imports necessary only on a
specific variant of the command.

The package named is also canonicalized only once, for a minor performance
improvement/to avoid extra work.

Only follow and lock links for packages of type `sdist` or `bdist_wheel`
in PyPi repository.

Closes: https://github.com/python-poetry/poetry/issues/3649
Closes: https://github.com/python-poetry/poetry/issues/4903

(This is a port of https://github.com/python-poetry/poetry/pull/3656.)

# Fix Shell Activation For ZSH

This PR resolves an issue wherein poetry will clear the `PATH` on zsh.
The activation script contains a number of if statements of the
following form:

```bash
    # ...
    if ! [ -z "${_OLD_VIRTUAL_PATH:+_}" ] ; then
        PATH="$_OLD_VIRTUAL_PATH"
        export PATH
        unset _OLD_VIRTUAL_PATH
    fi
```
These constructs are valid in bash, although zsh fails to negate the
conditional except when placed in emulation mode:

```zsh
# Causes PATH to be cleared, leading to other issues
. /home/alecto/.cache/pypoetry/virtualenvs/poetry-E-aAiPjf-py3.10/bin/activate
```

When bash is used as an emulator to source the script, it functions
correctly:

```zsh
# Functions correctly
emulate bash -c '. /home/alecto/.cache/pypoetry/virtualenvs/poetry-E-aAiPjf-py3.10/bin/activate'
```

It's important to note that this doesn't place the *entire* shell into
bash emulation mode; only the activate script is sourced as bash.

Any guidance on what tests should be added for this PR would be
appreciated.

Co-authored-by: Alecto Irene Perez <alecto.perez@voladynamics.com>
Co-authored-by: Bartosz Sokorski <b.sokorski@gmail.com>

This is a quick fix to avoid polluting stdout unexpectedly when Poetry's
environment management comes into play.

It's apparent from how much the complexity of this file has grown that
this needs to be refactored moderately, as well as each major class
deserving its own source file.

Future work should also include a rethink of how IO objects are passed
around the codebase, how we reason about verbosity at a function level,
and how code is re-used -- one command may wish to output to stdout, but
if that code is reused by another command, the calculus of what is
command output and what is informative (or even needs to be hidden/shown
based on verbosity level) changes.

Work on output would likely have to be fairly comprehensive and
invasive, but things have grown complex enough that a top-down design
pass is likely the best route.

Regardless, this is a simple change today, and low risk. Resolves #6427.