(Updated to reflect reality in April 2020)

This issue was initially scoped for changing the behavior of pip install --upgrade, by adding a new upgrade command with a different behavior when upgrading packages. The older recursive "eager" default caused grief for many (#304) However, after a lot of discussion on this, the approach taken was to add the --upgrade-strategy flag. The flag initially had a default of "eager" which was changed to a better default in #4500.

The tracking issue for "upgrade all packages" functionality is #4551.

What did you want to do?

One of CI jobs for Weblate is to install minimal versions of dependencies. We use requirements-builder to generate the minimal version requirements from the ranges we use normally.

The pip install -r requirements-min.txt command seems to loop infinitely after some time. This started to happen with 20.3, before it worked just fine.

Output

Requirement already satisfied: google-auth<2.0dev,>=1.21.1 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (1.23.0)
Requirement already satisfied: pytz>dev in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from celery[redis]==4.4.5->-r requirements-min.txt (line 3)) (2020.4)
Requirement already satisfied: googleapis-common-protos<2.0dev,>=1.6.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (1.52.0)
Requirement already satisfied: six>=1.9.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from bleach==3.1.1->-r requirements-min.txt (line 1)) (1.15.0)
Requirement already satisfied: protobuf>=3.12.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (3.14.0)
Requirement already satisfied: grpcio<2.0dev,>=1.29.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (1.33.2)
Requirement already satisfied: google-auth<2.0dev,>=1.21.1 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (1.23.0)
Requirement already satisfied: pytz>dev in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from celery[redis]==4.4.5->-r requirements-min.txt (line 3)) (2020.4)
Requirement already satisfied: googleapis-common-protos<2.0dev,>=1.6.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (1.52.0)
Requirement already satisfied: six>=1.9.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from bleach==3.1.1->-r requirements-min.txt (line 1)) (1.15.0)
Requirement already satisfied: protobuf>=3.12.0 in /opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages (from google-api-core[grpc]<2.0.0dev,>=1.22.0->google-cloud-translate==3.0.0->-r requirements-min.txt (line 63)) (3.14.0)

This seems to repeat forever (well for 3 hours so far, see https://github.com/WeblateOrg/weblate/runs/1474960864?check_suite_focus=true)

Additional information

Requirements file triggering this: requirements-min.txt

It takes quite some time until it gets to above loop. There is most likely something problematic in the dependencies set...

pip's dependency resolution algorithm is not a complete resolver. The current resolution logic has the following characteristics:

• Only one top level specification of a requirement (otherwise pip raises a "double requirement" exception)
• "first found wins" behavior for dependency requirements/constraints, which results in not respecting all constraints. pip 10+ print a warning when this occurs.

NOTE: In cases where the first found dependency is not sufficient, specifying the constraints for the dependency on the top level can be used to make it work.

pip install project "dependency>=1.5,<2.0"

(2019-06-23)

This is being worked on by @pradyunsg, in continuation of his GSoC 2017 project. A substantial amount of code cleanup has been done, and is ongoing, to make it tractable replace the current resolver, in a reasonable manner. This work enabled pip >= 10 to warn when it is going to make an installation that breaks the dependency graph. (The installations are not aborted in such scenarios, for backwards compatibility.)

(2019-11-29)

A status update regarding this is available here.

(2022-12-16)

See the closing note for details.

When pip is installed on a system that has an OS Python install there is currently a problem where pip install foo will throw an error because it doesn't have file permissions. This causes people to instead run sudo pip install foo which globally installs to the system Python. This creates an issue where people are using pip to manage system level packages when they should likely be using the system package manager.

So my intention is that pip should default to --user however there are a few sticking points with this:

• How does this interact with Windows? Does this make sense there?
• How does this interact with altinstall'd Pythons? Specially such as are installed with tools like https://github.com/yyuu/pyenv
• What do we do for when people do invoke pip as root? Installing into /root/.local/ does not seem very useful.
• What does this mean for get-pip and the pypa install instructions?
• ~/.local/bin is not on many people's $PATH, is there anything that can be done about this?
• --user installs lack precedence to global easy_install'd packages, which can be quite unexpected.

There are a number of issues that are relevant here: #624 #1443 #1153 #1500 #1051

/cc @ncoghlan

Hi there! If you're here from a message that's something like:

WARNING: Value for scheme.scripts does not match. Please report this to <https://github.com/pypa/pip/issues/9617

Please upgrade to the newest pip release (21.1.1 at the time of writing).

- @pradyunsg (on 3-May-2021)

First off, this specific class of warnings can be safely ignored. They were added to help pip's maintainers identify incorrectly patched/configured Python distributions provided by redistributors (eg: with your OS, or as part of $corp's VM/Docker images etc). You can read more about actionable steps for end-users, in this StackOverflow answer.

Secondly, if you came here to report the message: thank you! This issue has been locked now, since this warning has been significantly more widespread than we'd expected -- in other words there are lots of Python installations that are subtly wrong in a way that hasn't mattered till today. This warning has helped surface that and enables us to plan for a smoother transition in the future.

Thirdly, we've identified certain cases where the warning is overzealous, and we'll fix that in a bugfix release soon.

Finally, I encourage you to subscribe to this issue if you want to stay up to date with this issue. We'll be discussing how we're going to handle the various edge cases reported by the users, and also announce it here once there's a release containing those fixes.

- @pradyunsg (on 26-Apr-2021)

Assuming normal CPython deprecation and release cycles, distutils will be deprecated in 3.10 and removed in 3.12. This gives us a bit more than two years to make the transition happen. Unfortunately there are a lot of wanky downstreams we need to help transition correctly in the two years.

Fortunately, logic ins location.py is relatively cheap, so we can probably try to detect issues by calculating the locations from both sources, and warn when they don’t match. This will hopefully prompt users to find issues for us that we can forward to downstreams.

So the plan is:

1. Build a locations.py implementation that’s based entirely on sysconfig. Maintain the two implementations in parallel.
2. When a value is requested (e.g. locations.distutils_scheme()), check whether the two implementations produce the same value. Emit a warning if they don’t (and tell the user to report this). Return the value from the old implementation.
3. After a while, switch to return value to the new implementation. Keep the old value accessible via --use-deprecated. Keep warning when the two values don’t match.
4. Drop the old implementation (and the warning) when distutils is formally dropped in CPython master.

setuptools version

setuptools==56.0.0

Python version

Python 3.9

OS

Windows

Additional environment information

No response

Description

I use gui_scripts with a blank function. If i use pip install -e . or py setup.py install nothing happens, as expected. If i do pip install . or use setup.py to make a binary dist then install it, i get stderr duplication failed in a prompt. This happens before any code gets run.

Expected behavior

Nothing

How to Reproduce

# setup.py
from setuptools import setup

setup(
    name="test",
    packages=["test"],
    entry_points={
        "gui_scripts": [
            "test-script=test:main"
        ]
    }
)

# test/__init__.py
def main():
    pass

Run above commands

Output

Code of Conduct

• [x] I agree to follow the PSF Code of Conduct

Starting with pip 22.0, the HTML parsing is done using html.parser instead of html5lib by default. Along with this, there's an additional check to ensure that a valid HTML 5 doctype declaration is present in the document.

If you're here from a warning/error from pip's output:

• Please reach out to the provider of the package index you're using and ask them to change the index pages to be valid HTML 5 documents (declaring doctype, having the correct structure etc).
• You may pass --use-deprecated=html5lib until pip 22.2 (i.e. start of Q3 2022), when this flag will be dropped. This will suppress the warning for now, however you will no longer be able to pass this flag once pip 22.2 is released (and will need to fix the index pages to suppress the warning).

This behaviour change is motivated by two major factors:

• html5lib is the reason that pip pulls in dropping various other libraries, as part of its own dependency graph. Dropping html5lib and its dependencies from pip, enables reducing the maintainance workload on pip's maintainers and helps reduce the size of pip's distributions.
• The Python standard library's html.parser is more than sufficient for parsing the pages that pip needs to parse (see https://pypi.org/simple/pip/ for example).

~Barring major surprises, the flag to use html5lib will be removed in 22.1.~ There were surprises.

• The initial implementation of the html.parser-based parsing enforced that the page contains a doctype, throwing an error if it did not. Turns out, many third-party package indexes did not include a <!doctype html> in their index pages.
• With pip 22.0.1, certain bugs in the fallback logic were fixed, for pages that did not include the doctype.
• With pip 22.0.2, a fallback to the legacy html5lib logic was introduced, for pages that don't start with <!doctype html> (case-insensitive) with a warning presented to the user.
• With pip 22.0.3, the fallback to the legacy html5lib logic has been removed and the strict error in the html.parser logic has been relaxed to be a warning.
• With pip 22.0.4, the warning has been removed. Users will no longer get a warning on an invalid or missing doctype. However, this should still be fixed since a future version of pip may start rejecting such pages (after a deprecation period of ~3-6 months).

Overview

After upgrading to pip 10 or higher, many users are encountering error like

• ImportError: cannot import name 'main'
• TypeError: 'module' object is not callable
• ImportError: No module named _internal
• ModuleNotFoundError: No module named 'pip._internal'

These are caused by an incorrect attempt to upgrade pip, which has typically resulted in (parts of) multiple versions of pip being installed in the same Python installation, and those parts being incompatible.

It should be noted that these issues are invariably not problems with pip itself, but are due to incorrect use of pip, or unexpected interactions with system scripts that are not controlled by pip. So while we'll try to help you solve your issue, this is not the "fault" of pip, and you will have to be prepared to do at least some of the debugging and fixes on your own.

You can reach out to your Python provider (eg: Linux Distro, Cloud Provider, etc) for help with this issue.

General Advice

First, some general advice. It is assumed that anyone encountering issues will have failed to follow some part of this advice. Listing these items here is not intended to imply that "it's your fault and we won't help", but rather to help users to identify what went wrong, so that they can work out what to do next more easily.

1. Only ever use your system package manager to upgrade the system pip. The system installed pip is owned by the distribution, and if you don't use distribution-supplied tools to manage it, you will hit problems. Yes, we know pip says "you should upgrade with pip install -U pip" - that's true in a pip-managed installation, ideally distributions should patch this message to give appropriate instructions in the system pip, but they don't. We're working with them on this, but it's not going to happen soon (remember, we're looking at cases where people are upgrading old versions of pip here, so patches to new versions won't help).
2. Never use sudo with pip. This follows on from the first point. If you think you need to use sudo, you're probably trying to modify a distribution-owned file. See point 1.
3. Prefer to use --user. By doing this, you only ever install packages in your personal directories, and so you avoid interfering with the system copy of pip. But there are PATH issues you need to be aware of here. We'll cover these later. Put simply, it's possible to follow this advice, and still hit problems, because you're not actually running the wrapper you installed as --user.

Debugging the Issue

Before trying to work out what's going on, it's critically important that you understand precisely what scripts you are running and what versions of pip the relevant Python interpreter is using.

First, identify the full absolute path of the executable script that you are running. That's often in the traceback you get, but if it isn't, you can use OS tools like which, or Python's shutil.which to identify the right script. Watch out for your shell confusing the issue, with aliases or potentially stale hashed commands.

Once you have identified the script, make sure you can reproduce the problem using the absolute path to that script. If you can't, you probably found the wrong script, so check again.

Second, work out which version of Python the script is using to run pip. You'll often be able to get that from the shebang line of the script. This can often be the trickiest problem, as wrapper scripts can take many forms depending on what tool created them. In the worst case, you can simply make an intelligent guess at this point.

Once you know which Python is running pip, you can run python -m pip to invoke pip. In most cases, this will work fine, as it's the wrapper causing the issue, and not pip itself. Running pip via python -m in this way is often a perfectly acceptable workaround for the issue (at least in the short term).

Now run python -m pip --version. This will give you the exact version and location of the installation of pip that your Python is seeing.

At this point, you're usually done - the fundamental cause of all these problems is running a wrapper script which is written expecting to see a version of pip older than pip 10 (that's why it imports pip.main) under a Python interpreter that sees a copy of pip that's version 10 or later.

Fixing the Issue

The problem, of course, is fixing the issue. And that's where you really are on your own. If you have changed your system installation, you really need to put it back the way that the distribution installed it. That may well require an uninstall and reinstall of your distribution's pip package. Reinstalling is easy, of course - but uninstalling may require manually removing incorrect files. Or you may be able to force-reinstall with your distribution package manager, simply overwriting the incorrect files. Of course, this reverts you to the system-supplied version of pip. If you need a newer version, you should ask your distribution vendor, or use something like virtualenv to install it independently of your system packages.

It may be that you're simply running the "wrong" wrapper script. Maybe you did a --user install of a new version of pip, but your PATH is set to run the system version of the wrapper rather than the user-local one installed with pip. In that case, you can simply fix your PATH. That's usually the issue for people who do pip install --user --upgrade pip and get the pip.main error.

As already noted, python -m pip is a reliable workaround, at the cost of using a more verbose command to invoke pip.

Community Advice

The comments section of this issue is open for people to discuss specific problems, and to share potential solutions. Just to be clear, it's quite likely with problems of this nature that you'll need to modify system-supplied files or settings. You do so at your own risk. If you're not comfortable modifying your OS, or running as root, you should seek expert advice. To put it another way, if by following suggestions given here, you break your system, you get to keep the pieces. There's only so much that can be achieved remotely.

Also, the pip developers don't provide any guarantees that advice in the comments on this issue is correct, or that it won't damage your system. Again, use at your own risk.

Related Issues

The following issues have been reported which are related to this issue: #5240, #5221, #5588, #5495, #5493, #5487, #5447, #5432, #5373, #5326, #5318, #5253

This change accomplishes two principle objectives:

1. Moving the build isolation environment to be persistent throughout the build process. Because egg_info is invoked outside the wheel builder, the scope of the build environment should be (and is now here) the scope of req_install.
2. Moving setup.py interactions into a new class called build backend. The goal of this is to make all of the build backend functions pure except for self.setup_py_dir. We can then simply copy the build backend directly into setuptools, but it's faster to develop here first so that we can stay in a single project.

Actual implementation of PEP 517 functionality. This is not complete yet. Notes of outstanding actions:

• [x] Write tests for the new functionality (currently working on getting the existing tests working, to ensure no regressions).
• [x] Implement the --(no-)use-pep517 flag.
• [x] Move the patch to the vendored pep517 package back to the package itself.
• [x] Work out what to do about tests that depend on details of setuptools output.
• [x] Review remaining places where hook calls might be needed.
• [x] Documentation.
• [x] Implement --python-tag support.
• [x] Design review.

Probably others...

What's the problem this feature will solve?

I want to be able to manually remove the warning pip spews out during package installation in root environment:

Running pip as the 'root' user can result in broken permissions and conflicting behaviour ..

Describe the solution you'd like

I want to be able to disable this warning through an environment variable like

env PIP_DISABLE_ROOT_WARNING=1 pip install flask

Alternative Solutions

No in tool workaround known to me.

Additional context

We are all adults here, I know what I am doing and I do not want to see a warning every time I run my build system. Let me disable the warning by setting an environment variable. I do not want my users to think there is anything wrong my system just because of the pip tool spews out indiscriminate warning messages.

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

Filing an issue to track this since there's a lot of pieces involved as far as I can tell.

Blocked by:

• A concensus on the deprecation plan for legacy versions / requirements + rollout
• https://github.com/pypa/setuptools/pull/2822/ or some alternative

Needed to do:

• Improving error messages around bad requirements being provided to pip; notably https://github.com/pypa/packaging/pull/624
• Improving startup times (by removing pyparsing's parser initialization at import time from `packaging.requirement)
• PEP 685 (https://github.com/pypa/packaging/issues/545)
• Better handling of "old" MacOS tags

Resolves #11704

I would love to hear some thoughts on the message wording. I feel it's not very friendly right now because it doesn't specify how pip found the package. Should we log the finder class that found the package, maybe? Not sure if it's possible though without changing the importlib API.

What's the problem this feature will solve?

Due some problems around compatibilty of module/package often doing pip --upgarde, but if more modules touching this process then is easy to forgot what was previous version instaled and how to back to the right.

Describe the solution you'd like

pip history module geting some history of installation as eg. table module-name | datetime | version | process | | ----------- | ----------- | ----------- | | datetime | version | instaled | | datetime | version | uninstaled | | datetime | version | instaled | | datetime | version | instaled | | datetime | version | instaled |

It can be in sqlite

Alternative Solutions

Select for this register regarding headers as: pip history module datetime > 2023-01-05 pip history module datetime > 2023-01-05 and datetime < 2023-01-06 pip history module version 1.0 > and datetime < 5.0 pip history module process==uninstaled

Additional context

pip check modules Listing whole table with modules and curent release as pages +10 -10 https://github.com/pypa/pip/issues/11705 for table | module | datetime_instaled | version_instaled | datetime_new_release | version_new_release | | ----------- | ----------- | ----------- | ----------- | ----------- |
| module | datetime_instaled | version_instaled | datetime_new_release | version_new_release |

pip check modules datetime_new_release < 2023-01-05 pip check modules count_new_version > 5 - more than 5tags than curent modules in list pip check modules count_version - count all version for all pip show module count_version - count all version for module pip show module count_new_version > 5- more than 5tags than curent module as single

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

What's the problem this feature will solve?

I often don't know what is date realese of module/package, and sometimes is very outdated, then maybe should find other or care about some problems, other secuirty issues or bugs.

Describe the solution you'd like

1. Before install want information as some "meta" "info" about module/package:
2. Then want question like: Want to install? (y/n)
3. Select version: Last 10 version, form 0-9, where 0 current, and if 10 show more version

Alternative Solutions

If comand pip instal module -nq (no questions)

Additional context

Regarding 3. as Select version: Last 10 version, form 0-9, where 0 current, and if 10 show more version comand can be 10+ as next page with 10 list or back as -10 as previous page or maybe 20+ 30+ -20 -30

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

Description

I've encountered an issue with how pip handles custom Distributions that have their location atrribute set to None. As far as I understand, it's allowed, because the location type is here Optional: https://github.com/pypa/pip/blob/a057c9bc99ad7eab2e3b1539e79eee7d9a923f4f/src/pip/_internal/metadata/importlib/_compat.py#L34-L43

And

Not all distributions exist on disk

This is exactly my case — I have a custom meta_path finder that loads Distributions on the fly. When I'm trying to install an already installed package, pip finds an existing distribution and tries to log a message. It fails here when it tries to convert None to an absolute path (see below for the traceback).

https://github.com/pypa/pip/blob/a057c9bc99ad7eab2e3b1539e79eee7d9a923f4f/src/pip/_internal/req/req_install.py#L198

I can fix this internally by overriding the Distribution._path attribute, but I feel that it's better to resolve the underlying issue in pip itself. Perhaps we could fall back to a placeholder like <memory> in case the location is None.

I realise that this is a pretty rare case, and I'll be happy to submit a PR, if the proposed solution is acceptable.

Expected behavior

I think it's better to display a placeholder in case the location is None. Something like

$ pip install example
Requirement already satisfied: example in <memory> (1.0.0)

pip version

22.3.1

Python version

3.11.1

OS

macOS 12.6.2

How to Reproduce

• create a fresh virtualenv: python -m venv venv
• create a sitecustomize.py file in the virtualenv's site-packages directory with with the following contents:

import sys
from importlib.metadata import Distribution, DistributionFinder


EXAMPLE_METADATA = '''Metadata-Version: 2.1
Name: example
Version: 1.0.0

'''


class ExampleDistribution(Distribution):
    def locate_file(self, path):
        return path

    def read_text(self, filename):
        if filename == 'METADATA':
            return EXAMPLE_METADATA


class CustomFinder(DistributionFinder):
    def find_distributions(self, context=None):
        return [ExampleDistribution()]


sys.meta_path.append(CustomFinder())

• run pip install example

Output

$ pip install example
ERROR: Exception:
Traceback (most recent call last):
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 158, in _make_candidate_from_dist
    base = self._installed_candidate_cache[dist.canonical_name]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
KeyError: 'example'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/cli/base_command.py", line 160, in exc_logging_wrapper
    status = run_func(*args)
             ^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/cli/req_command.py", line 247, in wrapper
    return func(self, options, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/commands/install.py", line 400, in run
    requirement_set = resolver.resolve(
                      ^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 92, in resolve
    result = self._result = resolver.resolve(
                            ^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 481, in resolve
    state = resolution.resolve(requirements, max_rounds=max_rounds)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 348, in resolve
    self._add_to_criteria(self.state.criteria, r, parent=None)
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 147, in _add_to_criteria
    matches = self._p.find_matches(
              ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/provider.py", line 224, in find_matches
    return self._factory.find_candidates(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 424, in find_candidates
    return self._iter_found_candidates(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 320, in _iter_found_candidates
    _get_installed_candidate(),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 268, in _get_installed_candidate
    candidate = self._make_candidate_from_dist(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 160, in _make_candidate_from_dist
    base = AlreadyInstalledCandidate(dist, template, factory=self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 354, in __init__
    factory.preparer.prepare_installed_requirement(self._ireq, skip_reason)
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/operations/prepare.py", line 656, in prepare_installed_requirement
    logger.info(
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 1489, in info
    self._log(INFO, msg, args, **kwargs)
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 1634, in _log
    self.handle(record)
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 1644, in handle
    self.callHandlers(record)
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 1706, in callHandlers
    hdlr.handle(record)
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 978, in handle
    self.emit(record)
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/utils/logging.py", line 168, in emit
    message = self.format(record)
              ^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 953, in format
    return fmt.format(record)
           ^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/utils/logging.py", line 112, in format
    formatted = super().format(record)
                ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 687, in format
    record.message = record.getMessage()
                     ^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/.pyenv/versions/3.11.1/lib/python3.11/logging/__init__.py", line 377, in getMessage
    msg = msg % self.args
          ~~~~^~~~~~~~~~~
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/req/req_install.py", line 198, in __str__
    s += " in {}".format(display_path(self.satisfied_by.location))
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkono/personal/python/pip-none-path-example/venv/lib/python3.11/site-packages/pip/_internal/utils/misc.py", line 154, in display_path
    path = os.path.normcase(os.path.abspath(path))
                            ^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 399, in abspath
TypeError: expected str, bytes or os.PathLike object, not NoneType

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.