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

Originally reported by: Anonymous

---

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.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/125

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

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.

Original comment by kharlamov (Bitbucket: kharlamov, GitHub: 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.

Original comment by kharlamov (Bitbucket: kharlamov, GitHub: 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.

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

@philip_thiem Will you look into addressing this issue? If you use /dev/null, as prescribed, don't forget that the name is different on other platforms, so use os.path.devnull.

Original comment by kharlamov (Bitbucket: kharlamov, GitHub: 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)

Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever):

---

Or maybe use tempfile.mkdtemp().

Original comment by philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown):

---

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.

Original comment by philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown):

---

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.

Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever):

---

In 3a8a2da97325ff8a73943f4a208897c50596e2dd I improved code to use tempfile.TemporaryDirectory() from standard library when this function is available.

Original comment by philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown):

---

Good catch I was thinking to myself why the hell isn't there something like that. shakes head helps to look at the 3.3 docs instead of the 2.7.

Original comment by kharlamov (Bitbucket: kharlamov, GitHub: kharlamov):

---

Thank you very much for this.