I just tried it with my project setup and it worked for python setup.py build being executed in a subdirectory of my project. Great work!

One thing that did not work is the retrieval of the version when using the development version, e.g. when I just run python and then import my lib and check its version (import mylib; print(mylib.__version__). This returns 'unknown' as version.

For me this isn't a blocker, but perhaps there is an easy solution to make this work even in development mode?

I've rebased this branch and added some fixups (in "61-subprojects"). It's not entirely working for me yet: python setup.py version shows the right thing, but a pip install . does not (it gets 0+unknown, which is how versioneer says it can't find a git repo). I haven't tried pip install --editable . yet. But I'm working on it.

So, I now understand why pip install . is getting "0+unknown". It turns out that the very first thing pip install does is to copy os.path.dirname(setup_py) into a temporary directory, and then do everything else (egg_info, bdist_wheel) over there. Unfortunately, when our setup.py is in a subdirectory of the git tree, that copy doesn't include the .git/ directory like it usually does. So pip winds up doing a setup.py egg_info in a .git-less copy, and can't find any version data to work with.

python setup.py install would work (which uses eggs), as does pip install --editable . (since that doesn't try to make a copy first). But not pip install .

I don't know how to fix this. @dstufft says they want to make pip install . do a setup.py sdist instead of a copy, which would do the trick, but I don't know if there's a pip ticket open for that (pypa/pip#2195 is related), or what their timeline might be.

I'll add tests to the 61-subprojects branch to exercise the failing cases.

pypa/pip#3176 might be the pip PR that could fix this

I've added the extra tests to 61-subprojects. As expected, pip install from a "subproject" tree (where setup.cfg is not in the git root) fails, by getting a "0+unknown" version.

At this point, I think we're either waiting on a fix in pip, or we accept the test failures (mark them as TODO or something) and put a note in the docs that says you can't use "pip install ." from such a project. Unfortunately I think pip-install is the main use case for this, so I don't know if it's worth landing until that's fixed. On the other hand, all forms of install from a subproject tree are broken in versioneer-0.16, so maybe it's a step forward even though it's not exactly useful yet.

Ok, I've marked the relevant tests as "expected to fail", and I've added a section to the README about the limitations (basically that pip install . from a subproject directory will not get a useful version string, until/unless pip gets changed). I'm gonna land that branch, since I think it's still useful (especially since pip install --editable . ought to work). Please let me know if it seems to work for you too.