Description
I understand the reason why versioneer installs a script in the local directory, but with PEP 517 and PEP 518, we're moving towards a system with explicitly declared build dependencies and running builds in isolated environments.
Currently, if you specify build-backend="setuptools.build_meta" in your pyproject.toml, you need to also add sys.path.append(os.dirname(__file__)) into your setup.py in order to use versioneer.
However, if yo
6258
u're using PEP 517/518, that also means that you don't need to vendor your build dependencies in the source root anymore, you can just declare them in pyproject.toml. The difference in semantics between the PEP 517 backend and python setup.py commands also gives you a golden opportunity for "opportunistic upgrading". If you provide a version of versioneer that you can pip install, then anyone using versioneer can seamlessly upgrade to PEP 517 by simply adding versioneer to their pyproject.toml.
Currently, it fails because pip install versioneer installs a different versioneer module than the one that is picked up when you vendor it. I think you can make the PEP 517 transition much easier by giving projects a PyPI package they can depend on (maybe versioneer or versioneer-installed) that, when installed, puts the versioneer people are expecting on their environment's path.
Note that this is closely related to #192, though #192 is "versioneer breaks because of a behavior change in pip", whereas, when pip releases a new version, the issue will become "I have to add the source root to my sys.path if I want to use versioneer with the new setuptools build backends".