The only thing the versioneer-518 does is package the vendored code. It would be nice if the get_version call was available for use even if the code had not been vendored. At the time of writing development on versioneer had stalled and my 518 version seemed necessary. Now I agree that exposing the methods seems like the best route and would probably allow for some cleanup of the implementation.
The local versioneer.py will take precedence over site packages version so it won't affect any vendored installs. If that is not the case I think having versioneer installed would prevent building vendored versioneer packages since the module doesn't have the get_version call.

The local versioneer.py will take precedence over site packages version so it won't affect any vendored installs. If that is not the case I think having versioneer installed would prevent building vendored versioneer packages since the module doesn't have the get_version call.

I think that is sometimes the case, which leads some projects to add sys.path.insert(0, ".") to their setup.py. I don't fully understand why it seems to happen to some projects and not others.

@jwodder - would you be so kind to provide a review on this PR? My foo in Python build/dist/*-utils and corresponding PEPs is not that strong so can't really assess possible implications.

After letting this rest for a bit, I tried using it on a new repository and found this wasn't as ready as I remembered. Got around to adding versioneer setup to the base command that skips the versioneer install (vendoring) phase. Also added a test that demonstrates that it can work in python -m build's isolated build process. This required a hack to inject the current repository directory as versioneer @ file:///....

Will rebase and update the docs after #311.

I think we might want to consider the CLI a bit before pushing this out. Right now the installation process is:

versioneer install          # Vendors versioneer then runs setup
python versioneer.py setup  # Rerun setup from vendored versioneer

I'm currently proposing that this be possible to replace with versioneer setup or python -m versioneer setup which will skip the installation step and always use the environment-installed versioneer. This double-use of setup, even though it means the same thing, might hide when someone is accidentally invoking the environment versioneer instead of the vendored versioneer, potentially leading to subtle bugs. I think instead we want to revert to versioneer install for the main command and versioneer.py setup for the vendored module, and add a --vendor/--no-vendor flag.

versioneer install              # Vendors versioneer then runs setup
versioneer install --vendor     # Same as default
versioneer install --no-vendor  # Non-vendored setup

I will push this soon, but adding a comment to explain my reasoning.

Took a break to come back to this with fresh eyes. On the whole, I'm happy with it. Would anybody be interested in reviewing and/or test-driving? @bucknerns @yarikoptic?

I'm checking it out

@bucknerns FWIW I currently have to do this to get python -m build to work with isolation:

[build-system]
requires = [
    "setuptools",
    "versioneer @ file:///data/projects/versioneer/",
    "wheel"
]
build-backend = "setuptools.build_meta"

Once there's a release, it shouldn't be necessary. And I think python -m build --no-isolation should work without the @.

I'm checking it out

@bucknerns Any news?

Looks good, I pushed a copy to test.pypi.org and added to a pyproject.toml and did a pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ ./exampleproject of an example project to test it out.

fyi had to version lock it in the pyproject.toml but should be good on official version "versioneer==0.24.dev0"

Awesome! Thanks for the review. I'll merge now. I can write some release notes and pushing 0.24 to PyPI today or tomorrow, but feel free to go ahead and do it yourself.