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

XDG compliance for Unix/Linux (~/.config) #582

Merged
merged 10 commits into from
Oct 23, 2012
Merged

Conversation

TC01
Copy link
Contributor

@TC01 TC01 commented Jun 20, 2012

Currently, on everything but Windows, pip's configuration directory is located in ~/.pip. That is, a hidden directory in a user's home folder.

This pull request attempts to move away from this and towards the XDG specification (available here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html), which suggests that instead write configuration to $XDG_CONFIG_DIRS- which by default is ~/.config. So I've modified locations.py to do so.

I've also tried to ensure a migration path- if there is a pip.conf in the old ~/.pip folder that will get copied over to ~/.config/pip on pip's first run (after which it will be deleted).

There are a few issues this raises though:

  1. Should we be logging to the configuration folder? I'm not sure where else the logfile should be, but logging to a configuration folder feels... not quite right.
  2. If you run a command as root user (such as sudo pip install somepkg), pip will not look for a configuration file in your configuration folder but instead for one in /root/. This isn't a new issue (there are already long-open bugs like Provide a global (system-wide) config file. #309 about it), but as this pull request deals with config files.. I thought I'd mention it.

@travisbot
Copy link

This pull request passes (merged 5d9c7e5 into 4c96de6).

@pnasrat
Copy link
Contributor

pnasrat commented Jun 22, 2012

Please also update the docs and add to NEWS and yourself to AUTHORS if you are not in.

@TC01
Copy link
Contributor Author

TC01 commented Jun 24, 2012

There, I've now done both.

@travisbot
Copy link

This pull request fails (merged 0202fc8 into 4c96de6).

@pnasrat
Copy link
Contributor

pnasrat commented Jun 24, 2012

Failure was unrelated Executing your before_install (sudo apt-get install subversion bzr mercurial) took longer than 900 seconds and was terminated

@TC01
Copy link
Contributor Author

TC01 commented Jul 21, 2012

So... with an unrelated failure, is there something I have to do to get the pull request built again?

@pnasrat
Copy link
Contributor

pnasrat commented Oct 1, 2012

Sorry for lag - probably simplest now is to add something to docs/news.txt for this commit and push to same branch then travis should fire.

@pnasrat
Copy link
Contributor

pnasrat commented Oct 23, 2012

Looks like a slow build. I'll try running the tests locally before I merge.

pnasrat added a commit that referenced this pull request Oct 23, 2012
XDG compliance for Unix/Linux (~/.config)
@pnasrat pnasrat merged commit 319289f into pypa:develop Oct 23, 2012
qwcode added a commit that referenced this pull request Dec 27, 2012
@qwcode qwcode mentioned this pull request Apr 18, 2014
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants