Subprocess exited with error pip install

Another common cause of the error is misspelling the name of the package and trying to install some broken, obsolete module by mistake.

Check if your Python version is supported by the package #

The error «note: This error originates from a subprocess, and is likely not a problem with pip» is sometimes caused when the package you are trying to install doesn’t have available wheels for your version of Python.

You can check your Python version with the python —version command.

You can check if a package has wheels available for a specific Python version in the Download files section of the package’s pypi page.

If the .whl files are not available for your version of Python, you can download an older version.

The —pre option makes it so pip includes pre-release and development versions of the package. By default pip only finds stable versions.

If that didn’t work, you can download a specific Python version that is supported by the package if the package doesn’t support the latest Python version.

Different versions are available in the «Looking for a specific release» table.

Make sure to tick the following options if you get prompted:

• Install launcher for all users (recommended)
• Add Python to PATH (this adds Python to your PATH environment variable)

If that didn’t help and you don’t already have a virtual environment, try creating one.

Create a virtual environment #

To solve the «note: This error originates from a subprocess, and is likely not a problem with pip» error:

1. Create a virtual environment.
2. Activate the virtual environment.
3. Run the pip install command with the virtual environment active.

Make sure to use the correct command to activate your virtual environment depending on your operating system and your shell.

Your virtual environment will use the version of Python that was used to create it.

Try running pip install in verbose mode #

If none of the suggestions helped, try running the pip install command in verbose mode.

The -v option stands for verbose mode and can be used up to 3 times.

When the pip install command is run in verbose mode, the command shows more output and how the error occurred.

Conclusion #

To solve the error «note: This error originates from a subprocess, and is likely not a problem with pip»:

1. Upgrade your versions of pip , setuptools and wheel .
2. Make sure you haven’t got any missing dependencies.
3. Make sure your Python version is supported by the package.

Источник

Pip 22.1 (only) fails when included in pyproject.toml #11120

Description

Starting with pip 22.1, including «pip» in the pyproject.toml [build-system] requires fails.

Verified that this succeeds with pip 22.0.4

This error message repeatedly states that this is likely not a problem with pip. but it is the change from pip 22.0.4 to 22.1 that breaks it.

Expected behavior

I expect pip 22.1 to behave the same as pip 22.0.4; namely, that the installation succeeds.

Output when using pip 22.0.4:

pip version

Python version

Windows 11 (21H2)

How to Reproduce

1. Create a virtual environment and activate it
2. Install pip 22.1
3. Create a python package with a pyproject.toml containing:

1. Install this python package from the local directory with python -m pip install
2. Observe the error

Output

Code of Conduct

The text was updated successfully, but these errors were encountered:

You shouldn’t have pip in build-requires in the first place — why do you think you need it there?

The reason it’s failing is a somewhat complex combination of the fact that pip is already in the build environment to install everything else, pip can’t upgrade itself on Windows unless it’s invoked via python -m pip , and when setting up the build environment it looks like we invoke pip rather than python -m pip . It’s probably fixable, but messy to do so.

I don’t think this is worth fixing because you shouldn’t have pip in build-requires in the first place.

This might be something that we could prevent — I don’t have a Windows machine to be able to see why/what is happening. What’s happening here is that the environment is basically triggering the logic meant to protect users from a broken pip installation on Windows (see #1299).

It’s unclear to me why that’s happening, but we might have a spot where code needs to change from pip . to sys.executable -m pip . in the codebase — or some edge case that needs to be accounted for?

If someone is able to reproduce this, please plug a debugger into pip and share the values in the locals() and sys.argv[0] at:

modifying_pip and WINDOWS and os . path . basename ( sys . argv [ 0 ]) in pip_names

This error message repeatedly states that this is likely not a problem with pip.

Yea, this happening in a build step, where the typical failure is things like the package not having the appropriate build-time dependencies installed. The use of the word likely points toward that. 🙂

@pradyunsg this is indeed probably the solution, although we may be invoking the build environment’s pip at this point, so sys.executable might be the wrong thing to use.

As I say, it’s possible, but tricky, and I’d like to know why the OP wants to include pip in build-system.requires before we «fix» this.

Bah, you’re right — I missed that nuance. 🙂

You shouldn’t have pip in build-requires in the first place — why do you think you need it there?

. I had no reason to think it didn’t need to be there? It needs setuptools and wheel to be there. Why do those need to be there and not pip? The documentation states that build-system.requires is a list of requirement specifiers for build-time dependencies of a package. It seems like pip is a build-time dependency of my package. I don’t see how it can pip install if the user doesn’t even have pip.

If no pyproject.toml should ever have pip in build-system.requires , then the documentation does not make this clear.

If no pyproject.toml should ever have pip in build-system.requires, then the documentation does not make this clear.

build-system.requires is intended to be «the things you need in the environment order to build the project». It’s the front end’s responsibility to install those items into the environment and to call the build_wheel hook of the backend in that environment. That build frontend might be pip or it might be something else. But it doesn’t need to be in the environment because it orchestrates the creation and use of that environment.

I don’t think it ever occurred to me that people might think pip needed to be added into the build environment. If you were building a wheel using build would you expect to put build in there? How can you know what frontend the user is invoking? But if you have a suggestion for improving the documentation, that would be great! I guess the first question is which documentation you’d want to improve — this stuff is generally covered in packaging.python.org, not in pip’s documentation, so a PR there might be the best approach.

This is covered in pip’s documentation, as part of https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/#build-time-dependencies, which might be the sentence that is the source of the confusion here.

Is this still happening in 22.1.1?

. I had no reason to think it didn’t need to be there? It needs setuptools and wheel to be there

Why does wheel need to be there? Setuptools lists it as a dependency for building wheels and is automatically installed when necessary.

It used to not do that, in earlier versions of setuptools.

Источник

Can’t install #433

I am trying to install the package but pip keeps failing. The error I get is this:

Collecting PyBluez
Using cached PyBluez-0.23.tar.gz (97 kB)
Preparing metadata (setup.py) . error
error: subprocess-exited-with-error

× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
error in PyBluez setup command: use_2to3 is invalid.
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

The text was updated successfully, but these errors were encountered:

— a caller that pip uses to run setup.py # # — It imports setuptools before invoking setup.py, to enable projects that directly # import from `distutils.core` to work with newer packaging standards. # — It provides a clear error message when setuptools is not installed. # — It sets `sys.argv[0]` to the underlying `setup.py`, when invoking `setup.py` so # setuptools doesn’»‘»‘t think the script is `-c`. This avoids the following warning: # manifest_maker: standard file ‘»‘»‘-c’»‘»‘ not found». # — It generates a shim setup.py, for handling setup.cfg-only projects. import os, sys, tokenize try: import setuptools except ImportError as error: print( «ERROR: Can not execute `setup.py` since setuptools is not available in » «the build environment.», file=sys.stderr, ) sys.exit(1) __file__ = %r sys.argv[0] = __file__ if os.path.exists(__file__): filename = __file__ with tokenize.open(__file__) as f: setup_py_code = f.read() else: filename = «» setup_py_code = «from setuptools import setup; setup()» exec(compile(setup_py_code, filename, «exec»)) ‘»‘»»»‘»»»‘»‘ % (‘»‘»‘/tmp/pip-install-68qwtmvz/pybluez_c1c9b215cbe7493a9f160507e1e4e9c2/setup.py’»‘»‘,), «

«, «exec»))’ egg_info —egg-base /tmp/pip-pip-egg-info-ew_2egyz cwd: /tmp/pip-install-68qwtmvz/pybluez_c1c9b215cbe7493a9f160507e1e4e9c2/ Preparing metadata (setup.py) . error error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. «>

Related issues (did not check them for solutions yet):
#413 #424 #431

This was fixed in #431 — Solution for now, until a new release is pushed to pypi is:

Источник

Ошибка подпроцесса при установке Kivy на Windows. Что делать?

Я пытался установить Kivy через pip по инструкции с официального сайта, однако, при попытке установки консоль выдаёт следующую ошибку:

Если это важно, у меня стоит python 3.10.

Как решить данную проблему?

• Вопрос задан 06 февр. 2022
• 3479 просмотров

Потихонечку откатываемся на python 3.8

Также, если есть желание, перед установкой любой библиотеки, желательно почитать офф. инструкцию по установке:
Kivy 2.0.0 officially supports Python versions 3.6 — 3.9. — второе предложение в инструкции!

Потихонечку откатываемся на python 3.8

А если серьёзно, у вас он работает с 3.9?

3.7, 3.8, 3.9 — тут вообще без разницы, абсолютно.

Тем более, последние версии не опытным пользователям привозят только вагон и маленькую тележку проблем.

Если без разницы, тогда почему 3.8?

Какие проблемы привозит 3.9 в отличие от 3.8?

Как вариант, меньшее количество пакетов, доступных через pip install. Конечно, можно большинство пакетов в Python 3.9, 3.10. установить из исходников, но новички этим заниматься не будут!

Источник