Previously, the special case to generate 'pip' and 'easy_install' entry
points with the correct Python version (e.g. 'pip3.9' on Python 3.9)
only accounted for single-digit version segments, and did not work
correctly on Python 3.10 and up. This was missed when Python 3.10 was
released because we (accidentally) generated wheels that did not need
any such replacements, but was exposed in CPython 3.11.0 since it
bundled pip 22.3 generated against Python 3.10.
The code to do this already exists in `get_csv_rows_for_installed`, but it's
broken due to inconsistent usage of the `_fs_to_record_path` function. When
we build the dictionary of installed files, we call it with a base
directory, while when build the set of modified files, we call it without a
base directory. As a result, the values of `installed` do not match the
elements of `changed`, and `get_csv_rows_for_installed` fails to identify
the rows that should be updated.
Fix this by ensuring that `_fs_to_record_path` is always called with a base
directory. `_record_to_fs_path` also needs a a base directory parameter to
be able to transform the path back into an absolute path, so add one.
- Remove unnecessary uses of six functions. With Python 2 support
dropped, the text/bytes boundaries are more explicit and don't require
type coercion. This allows dropping the types-six dependency.
- Remove Python 2 workarounds and comments describing those workarounds.
This notably gets us on a version of mypy that uses modular typeshed:
https://mypy-lang.blogspot.com/2021/05/the-upcoming-switch-to-modular-typeshed.html
which allows us to have finer control over what version of stubs we pull
in from typeshed. Also contains other routine improvements to mypy.
Required a few minor typing changes.
Add flag --show-error-code so errors look like this
src/pip/_internal/network/auth.py:70: error: Incompatible types in assignment
(expression has type "None", variable has type Module) [assignment]
rather than
src/pip/_internal/network/auth.py:70: error: Incompatible types in assignment
(expression has type "None", variable has type Module)
The typing module has been available since Python 3.5. Guarding the
import has been unnecessary since dropping Python 2.
Some guards remain to either:
- Avoid circular imports
- Importing objects that are also guarded by typing.TYPE_CHECKING
- Avoid mypy_extensions dependency
The stdlib module has been available since Python 3.5 and the
TYPE_CHECKING constant has been available since 3.5.2.
By using stdlib, this removes the need for pip to maintain its own
Python 2 typing compatibility shim.
The object returned by NamedTemporaryFile delegates all functions calls
to the underlying file so can avoid the type override by relying on IO
methods.
Use pyupgrade to convert simple string formatting to use f-string
syntax. pyupgrade is intentionally timid and will not create an f-string
if it would make the expression longer or if the substitution parameters
are anything but simple names or dotted names.
Originally we would throw an `AttributeError` if a bad scheme key was
used. After refactoring we would throw a `KeyError`, which isn't much
better. Now we call out the wheel being processed, scheme key we didn't
recognize, and provide a list of the valid scheme keys. This would
likely be useful for people developing/testing the wheel.
Previously our wheel installation process allowed wheels which contained
non-conforming contents in a contained .data directory.
After the refactoring to enable direct-from-wheel installation, pip
throws an exception when encountering these wheels, but does not include
any helpful information to pinpoint the cause.
Now if we encounter such a wheel, we trace an error that includes the
name of the requirement we're trying to install, the path to the wheel
file, the path we didn't understand, and a hint about what we expect.
Moving this value up from `_install_wheel` means that we do not need to
pass `req_description` anymore. This will also let us move our
entrypoint error handling around without worrying about losing the
context from the previous message.
Now we rely solely on the list of RECORD-like paths derived from the
filesystem, and can easily trade out the implementation for one that
comes from the wheel file directly.
At the beginning of our wheel processing we are going to have the list
of contained files. By splitting this into its own function, and
deriving it from disk in the same way it will appear in the zip, we can
incrementally refactor our approach using the same interface that will
be available at that time.
We start with the root-scheme paths (that end up in lib_dir) first.
When we start processing files directly from the wheel, all we will have
are the files with their zip path (which should match a `RECORD`
entry). Separating this from the source file path (used for copying)
and annotating it with our `RecordPath` type makes it clear what the
format of this public property is, and that it should match what is in
`RECORD`.
We always pass a file path to this function, so assert as much. We want
the return type to be consistent so we can assign the result to
non-Optional types.
"getting files" is one of the places that requires files to be on disk.
By extracting this out of `clobber` we can make it simpler and then
trade it out for a zip-based implementation.
Damian Shaw
Christian Clauss
lorddavidiii
Tzu-ping Chung
hauntsaninja
Роман Донченко
q0w
Jon Dufresne
Pradyun Gedam
Nipunn Koorapati
harupy
Inada Naoki
Pradyun Gedam
Hugo van Kemenade
Chris Hunt
Nguyễn Gia Phong