The. syntax installs the project defined in the current directory. It doesn't know anything aboutrequirements.txt, but it does know aboutsetup.py, as well as the more modernsetup.cfg andpyproject.toml.

It also can handle build backends that are not currently installed. For example, starting in Python 3.12,setuptools is not automatically installed, so in fresh Python 3.12 virtual environments asetup.py script cannot be run directly, butpip install . will still manage to run it. (This is the "Installing backend dependencies" step sometimes shown inpip output.) This works for backends other thansetuptools, too. For example, a project that usespoetry and defines everything inpyproject.toml in a way onlypoetry understands can be installed withpip install . even ifpoetry is absent;pip installs thepoetry build backend.

Sosetup.py is actually providing the dependencies thatpip install . installs for gitdb:

That happens to be the same as inrequirements.txt, but it doesn't have to be. If it weren't, installing fromrequirements.txt could make something succeed that would fail when the package is installed from PyPI (hence why I regardpip install . to be a better way to install required dependencies before running tests).

Althoughpip install . doesn't userequirements.txt, it will still be used ifsetup.pyreads anduses it, as is the case in GitPython.

The other benefit ofpip install . is that it installs the project, not just its dependencies. Because this is installing a package--albeit one that it is building on the fly from the working directory--it more closely matches what happens when the project is installed from PyPI. A middle ground can be achieved by also passing-e/--editable, which "installs a package" but the package is just the local files, rather than copies of them. This is very useful for local development, because changes are immediately reflected in the "installed package," but it's not necessary for CI.

(Of course, another way to test behavior of a built sdist or wheel is to actually build one and install from it in a new environment, which tools liketox andnox automate. I do not claim that usingpip install . achieves that level of similarity to installing from PyPI.)

Thanks a lot for the explanation, it's much appreciated.

The other benefit ofpip install . is that it installs the project, not just its dependencies. Because this is installing a package--albeit one that it is building on the fly from the working directory--it more closely matches what happens when the project is installed from PyPI. A middle ground can be achieved by also passing-e/--editable, which "installs a package" but the package is just the local files, rather than copies of them.

The-e flag seems like the secret ingredient that I have been missing for a long time now. I simply wasn't able to run GitPython locally anymore once the hacks that I added early on (a decade ago?) to allow that were removed.