Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add missing pip in $PATH on Cygwin CI
This makes a pip -> pip3 symlink in /usr/bin in a new step prior to the first step that runs the pip command. Using "pip3", "pip3.9", or a command like "python -m pip" would work, but this allows the Cygwin workflow to continue using the same installation commands as the main testing workflow. Adding this fixes two problems: 1. When the pip version installed by the python39-pip Cygwin package is current, so that upgrading pip doesn't install any new commmand, no "pip" command is created in /usr/local. This has happened not to be the case for a long time, which is why the Cygwin workflow was able to pass. (That the recent failures started at the merge of gitpython-developers#1783 turns out to be a coincidence: rerunning jobs on prior commits has the failure, as does experimentally reverting it.) 2. Even when the pip version installed by python39-pip is behind the latest available version, pip is still used before being upgraded to check if setuptools is installed, to decide whether to upgrade it. This is to keep similar steps in the two testing workflows similar, since the Cygwin workflow only uses Python 3.9, which always has setuptools. Because pip was never in $PATH in that step, the Cygwin workflow wrongly refrained from trying to upgrade setuptools. When the "Update PyPA packages" step does find a newer version of pip to upgrade to, it installs it in /usr/local/bin, which we have in $PATH before /usr/bin, so the upgraded version, when present, will still be preferred in subsequent commands, as before. Running "pip" on Cygwin when it may not be in $PATH -- and, for one step, never is -- was a bug introduced in e8956e5 (gitpython-developers#1709). Before that, "pip" still was not always available, but it was not used. This change fixes the bug by making sure "pip" is always available.
- Loading branch information