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
setuptools leaves a ~/.subversion dir laying around after it completes #125
Comments
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 Also, doing I hope that setuptools can be made to do one of these. |
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 ALSO: The check for SVN was not right. Decided on files to only check for Test passed on CPytonh 2.x and 2.3 on windows, travis-ci, and travis-ci/mac. |
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. |
Originally reported by: Anonymous
When I do
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.
The text was updated successfully, but these errors were encountered: