Issue #125 resolved

setuptools leaves a ~/.subversion dir laying around after it completes

Anonymous created an issue

When I do

easy_install -Z --upgrade setup tools

A directory, ~/.subversion, is created and then not cleaned up afterwards. I don't use subversion, and I don't want its parts cluttering up my $HOME. If this dir is necessary for completing the easy_install operation, shouldn't it be put into a tmpdir that later gets cleaned up?

I see this behavior on at least MacOSX 10.9 and 10.8.5.

Comments (12)

  1. Jason R. Coombs

    The setuptools code base doesn't include ".subversion" anywhere in it. Also, this issue doesn't appear to be present in my Windows or Linux environments. I suspect it's not setuptools that's adding the directory, but the invocation of 'svn' itself (as the setuptools plugin will invoke to test for its presence).

    Can you confirm that the 'svn' command is installed? Since you don't need it, can you remove it? If you remove it and then re-run the upgrade of setuptools, does the .subversion directory not get created?

    Eventually I'd like to move the subversion support into a separate, optional package, but for the sake of the reported bug, I don't think there's an easy fix.

  2. kharlamov

    'svn' is indeed there, because it's built-in to OS X (at least once XCode and the command-line tools are installed). I could remove it, but won't, because it's in /usr/bin.

    Testing reveals that even 'svn --version' creates the dir in question.

    Possibly there is some flag for 'svn' that will prevent the creation of the .subversion dir in $HOME. I will look into this now.

  3. kharlamov

    Doing svn --config-dir $TMPDIR will create the dir in question inside $TMPDIR and not leave it cluttering up $HOME.

    Also, doing svn --config-dir /dev/null --version will cause svn to display a one-line error message (which tells you that svn exists), and will display the version anyway (after the error message). This also does not leave '.subversion' cluttering up $HOME.

    I hope that setuptools can be made to do one of these.

  4. kharlamov

    Specifically on OSX 10.9.1, the first two lines of output from the dev/null command above are:

    svn: warning: W000020: Can't open file '/dev/null/servers': Not a directory
    svn, version 1.7.10 (r1485443)
    
  5. philip_thiem

    Well normally on POSIX platforms dot directories are created for caching and user settings. This would include darwin. It wouldn't be terrible unusual for any utilities to create directories in the user's home directory for whatever reason. My Linux home directories typically have 50+ of these types of directories. Frequently, file managers hide these directories so they don't visually clutter the directories; even ls doesn't list .* without the -a parameter

    That said, svn --version probably should not create the directory in ~/ or %userprofile% because it shouldn't have to do anything. So I think that should be a svn bug. We could workaround it as indicated, but might be a good idea to follow up with the apache foundation.

    After svn --version, there should be a check to see if we are in an svn repository. This is either a called to svn or svnversion. Either a workaround like this or this could be replaced with a upwards directory crawl looking for ".svn" (since 1.7 .svn might not exist in the current) should work.

    For the actual svn queries, this behavior might have to exist to capture user configuration. This would only matter for instances inside an svn working directory. So fixing the two previous things should clear things up for kharlamov.

    The workarounds proposed look pretty good, I'll take a closer look when I have a bit more time tomorrow.

  6. philip_thiem

    Fixed Issue #125: setuptools leaves a ~/.subversion dir laying around after it completes This is the best that can probably be done. Temporary directories are used for get the svn binary version and to get the initial directory info (for determining if one is, in fact, in a svn working directory)

    ALSO: The check for SVN was not right. Decided on files to only check for .svn/entries because missing properties just leaves out the external refs. And then incorporated a test on the code to make sure that svn info completed.

    Test passed on CPytonh 2.x and 2.3 on windows, travis-ci, and travis-ci/mac. Note: There seems to be an issue with pypy and a test.

    → <<cset f2e84bb07291>>

  7. Log in to comment