Could not build wheels for _ which use PEP 517 and cannot be installed directly – Easy Solution
Question:
I am trying to install a package which uses PEP 517. The newest version of Pip won’t allow me to install due to an error involving wheel building for 517.
In the past, I’ve solved this issue by downgrading Pip, installing the package and Upgrading Pip back to the latest version. However, after I downgrade pip in my virtualenv, if I try to run ‘Pip install black’ I get the No module named ‘pip._internal.cli.main’ error.
How can I solve this?
Answers:
The easiest solution to deal with the error
"Could not build wheels for ____ which use PEP 517 and cannot be installed directly"
is the following:
sudo pip3 install _____ --no-binary :all:
Where ____ is obviously the name of the library you want to install.
This error came up for the h5py library during the installation of Tensorflow. I checked the h5py documentation to make sure I had the right versions of pip and setuptools, https://pip.pypa.io/en/stable/reference/pip/.
pip install --upgrade pip setuptools wheel
I then checked the error log to identify what has caused h5py to fail while installing backend dependencies. I identified it was the libhdf5.so, where it says "error: libhdf5.so cannot open shared object file: No such file or directory". I installed the library by running:
sudo apt-get install libhdf5-dev
After this, the h5py installed successfully alongside TensorFlow.
I’ve come across similar PEP 517 errors caused by missing dependencies:
- ERROR: Could not build wheels for glpk which use PEP 517 and cannot be installed directly
- ERROR: Could not build wheels for scipy which use PEP 517 and cannot be installed directly
Posting an answer as reference for future searchers here.
I tried installing Pillow and got this error. Tried many different approaches, none of them worked.
Then i downgraded Python (From 3.9) to 3.8 and just tried installing by pip again, then it worked.
If it fails for you, try downgrading Python, and it may work.
Sometimes this can be due to a cache issue and the no-binary flag won’t work. In which case try pip install <insert package names> --no-cache-dir.
This seems to be a frequent issue when installing packages with python. First, check to ensure you have activated the virtualenv you think you’re supposed to be in, then check to see if you have wheels pkg (pip install wheel if not). If those fail then the –no-cache-dir or –no-binary flags come into play. Reading the pypi documentation on each package could help as well. Best of luck!
When I ran into this error, the problem was that the package I was pulling had its metadata configured incorrectly, which caused building the wheels to fail.
To find that error I ran, pip --verbose install <my_package> Which let me see what about the wheel build was failing, and fix it upstream.
I have also encountered the same issue when uninstalling and reinstalling miniconda.
I have no idea why, but in my registry key ComputerHKEY_CURRENT_USERSOFTWAREMicrosoftCommand Processor AutoRun has been set to if exist. I deleted the value then it worked fine just as before.
On OSX setting SYSTEM_VERSION_COMPAT=1 in my environment prior to running pip solved it:
export SYSTEM_VERSION_COMPAT=1
This solution from this link helped me:
pip install --upgrade pip setuptools wheel
try this:
pip3 install –upgrade pip
I am trying to install a package which uses PEP 517. The newest version of Pip won’t allow me to install due to an error involving wheel building for 517.
In the past, I’ve solved this issue by downgrading Pip, installing the package and Upgrading Pip back to the latest version. However, after I downgrade pip in my virtualenv, if I try to run ‘Pip install black’ I get the No module named ‘pip._internal.cli.main’ error.
How can I solve this?
The easiest solution to deal with the error
"Could not build wheels for ____ which use PEP 517 and cannot be installed directly"
is the following:
sudo pip3 install _____ --no-binary :all:
Where ____ is obviously the name of the library you want to install.
This error came up for the h5py library during the installation of Tensorflow. I checked the h5py documentation to make sure I had the right versions of pip and setuptools, https://pip.pypa.io/en/stable/reference/pip/.
pip install --upgrade pip setuptools wheel
I then checked the error log to identify what has caused h5py to fail while installing backend dependencies. I identified it was the libhdf5.so, where it says "error: libhdf5.so cannot open shared object file: No such file or directory". I installed the library by running:
sudo apt-get install libhdf5-dev
After this, the h5py installed successfully alongside TensorFlow.
I’ve come across similar PEP 517 errors caused by missing dependencies:
- ERROR: Could not build wheels for glpk which use PEP 517 and cannot be installed directly
- ERROR: Could not build wheels for scipy which use PEP 517 and cannot be installed directly
Posting an answer as reference for future searchers here.
I tried installing Pillow and got this error. Tried many different approaches, none of them worked.
Then i downgraded Python (From 3.9) to 3.8 and just tried installing by pip again, then it worked.
If it fails for you, try downgrading Python, and it may work.
Sometimes this can be due to a cache issue and the no-binary flag won’t work. In which case try pip install <insert package names> --no-cache-dir.
This seems to be a frequent issue when installing packages with python. First, check to ensure you have activated the virtualenv you think you’re supposed to be in, then check to see if you have wheels pkg (pip install wheel if not). If those fail then the –no-cache-dir or –no-binary flags come into play. Reading the pypi documentation on each package could help as well. Best of luck!
When I ran into this error, the problem was that the package I was pulling had its metadata configured incorrectly, which caused building the wheels to fail.
To find that error I ran, pip --verbose install <my_package> Which let me see what about the wheel build was failing, and fix it upstream.
I have also encountered the same issue when uninstalling and reinstalling miniconda.
I have no idea why, but in my registry key ComputerHKEY_CURRENT_USERSOFTWAREMicrosoftCommand Processor AutoRun has been set to if exist. I deleted the value then it worked fine just as before.
On OSX setting SYSTEM_VERSION_COMPAT=1 in my environment prior to running pip solved it:
export SYSTEM_VERSION_COMPAT=1
This solution from this link helped me:
pip install --upgrade pip setuptools wheel
try this:
pip3 install –upgrade pip