Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for locating setup.py below the git repo root #61

Closed
wants to merge 6 commits into from

Conversation

mcbridejc
Copy link
Contributor

This addresses issue #38.

versioneer is the best way that I've come across to manage automated versioning of python projects. I know it isn't the standard practice, but I do have a case where I have a python module that is part of a larger project that lives within a single repo, and I wanted to be able to use versioneer for this as well.

This does a few things:

  1. Adds a test case where the git repo is created in demoapp, but the setup.py and other files are created in demoapp/project
  2. In git_versions_from_vcs(), it uses git command return to test for a git directory, rather than looking for a .git directory
  3. In versions_from_parentdir(), it will search up two levels of directory hierarchy trying to find a directory name that matches the configured prefix.

…ry below the git root directory

The other tests are back to passing, and the new test is failing for what appears
to be a reasonable reason.
…rt for sub directory projects

1) I'm removing the creation of the "false-repo" in the test parent directory.

I'm not sure what the reasoning behind this was, and based on the behavior I'm
trying to add, this directory should be used to infer version if present.

2) Git add paths for SC were incorrect when the project files were placed in a
sub-directory.
…g for a .git directory

This means that the python module may be located in a sub-directory instead
of the git root directory, and versioneer will still be able to find the
version.
# up two directory levels for an appropriately named parent directory
rootdirs = []

for i in range(3):
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a special reason for the limitation to 3 parent directories? What if I have a deeper nested structure?

@wulmer
Copy link

wulmer commented Oct 1, 2015

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?

@warner warner modified the milestones: 0.17, 0.16 Mar 31, 2016
@warner
Copy link
Collaborator

warner commented Apr 12, 2016

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.

@warner
Copy link
Collaborator

warner commented Apr 13, 2016

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.

@warner
Copy link
Collaborator

warner commented Apr 13, 2016

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

@warner
Copy link
Collaborator

warner commented Apr 13, 2016

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.

@warner
Copy link
Collaborator

warner commented Apr 15, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants