MSYS2: pip is not in path after installation (command not found)
Question:
I installed pip on MSYS2 using the following command in the MSYS2 shell:
pacman -S mingw-w64-x86_64-python-pip
(web page for the package: https://packages.msys2.org/package/mingw-w64-x86_64-python-pip)
After installing, when I try to run pip in the MSYS2 shell I get: bash: pip: command not found
For some reason, it didn’t install pip anywhere in the MSYS2 system path. There is no file called "pip" in C:msys64usrbin. The installation did, however, add a file called "pip" in C:msys64mingw64bin. This directory is not part of the default path that MSYS2 uses.
Am I supposed to add C:msys64mingw64bin to my MSYS2 PATH? More importantly, why did it install pip to a directory that isn’t in PATH? Is there a reason for this annoyance?
Answers:
As the documentation explains, the MSYS2 project consists of two sections: MinGW and MSYS proper. The differences between them are as follows:
- MinGW packages are native Windows binaries that are themselves used to build native Windows software. They can be run independently from MSYS, although MSYS can ease their use, for example by providing a Unix-like shell scripting language.
- (Proper) MSYS packages run in a virtual POSIX environment that serves as a build system meant to bootstrap the rest of MSYS2. It incorporates enough POSIX features (e.g. a familiar
/bin, /lib, /etc, etc. directory structure) to allow porting software from Unix-like systems without having to extensively adapt it to the Windows platform. Development tools in the MSYS section are used to build software that depends on the MSYS environment.
The mingw-w64-x86_64-python-pip package belongs to the MinGW section. In order to use it, you need to launch a MinGW shell, so that you have access to the MinGW environment used to build native Windows software. If you want to have pip available in the MSYS shell, you need to install the MSYS package python-pip.
As for manually adding /mingw64/bin to your PATH: no, you are absolutely not supposed to do that. Mixing environments in this way is not supported; the whole point is for them to be separate.
I installed pip on MSYS2 using the following command in the MSYS2 shell:
pacman -S mingw-w64-x86_64-python-pip
(web page for the package: https://packages.msys2.org/package/mingw-w64-x86_64-python-pip)
After installing, when I try to run pip in the MSYS2 shell I get: bash: pip: command not found
For some reason, it didn’t install pip anywhere in the MSYS2 system path. There is no file called "pip" in C:msys64usrbin. The installation did, however, add a file called "pip" in C:msys64mingw64bin. This directory is not part of the default path that MSYS2 uses.
Am I supposed to add C:msys64mingw64bin to my MSYS2 PATH? More importantly, why did it install pip to a directory that isn’t in PATH? Is there a reason for this annoyance?
As the documentation explains, the MSYS2 project consists of two sections: MinGW and MSYS proper. The differences between them are as follows:
- MinGW packages are native Windows binaries that are themselves used to build native Windows software. They can be run independently from MSYS, although MSYS can ease their use, for example by providing a Unix-like shell scripting language.
- (Proper) MSYS packages run in a virtual POSIX environment that serves as a build system meant to bootstrap the rest of MSYS2. It incorporates enough POSIX features (e.g. a familiar
/bin,/lib,/etc, etc. directory structure) to allow porting software from Unix-like systems without having to extensively adapt it to the Windows platform. Development tools in the MSYS section are used to build software that depends on the MSYS environment.
The mingw-w64-x86_64-python-pip package belongs to the MinGW section. In order to use it, you need to launch a MinGW shell, so that you have access to the MinGW environment used to build native Windows software. If you want to have pip available in the MSYS shell, you need to install the MSYS package python-pip.
As for manually adding /mingw64/bin to your PATH: no, you are absolutely not supposed to do that. Mixing environments in this way is not supported; the whole point is for them to be separate.