Windows Config File Location Inconsistencies

[kpersohn]

The documentation (as of writing) says:
User: %APPDATA%\pip\pip.ini
Legacy: %HOME%\pip\pip.ini
Virtualenv: %VIRTUAL_ENV%\pip.ini
Site: %PROGRAMDATA%\PyPA\pip\pip.conf

Based on code inspection and what's actually ignored/respected I think this is reality:
User: %APPDATA%\pip\pip.ini
Legacy: %HOME%\pip\pip.ini
Virtualenv: %VIRTUAL_ENV%\pip.ini
Site: %PROGRAMDATA%\pip\pip.ini (no vendor folder, wrong extension)

From what I read in #309, #1733, and #1978 I think this was the intention:
User: %APPDATA%\pip\pip.conf
Legacy: %HOME%\pip\pip.ini
Virtualenv: %VIRTUAL_ENV%\pip.conf
Site: %PROGRAMDATA%\pip\pip.conf

Basically, I'm proposing to omit the "vendor" folder from the documentation and actually use the .conf extension consistently instead of .ini, except in the legacy case of course.

I'd be happy to propose a reconciliation PR if there's a general consensus I've got my facts straight.

[dstufft]

I think that we decided on vendor-less folders because @pfmoore said that was normal enough. If the code does that then that should be updated.

As far as extensions go, I don't feel strongly about what extension Windows uses. I do think if we change it we should make sure the old .ini still work even in the "new" locations.

[kpersohn]

I'd be perfectly content just getting the documentation and the code to match the status quo without changing extensions. I just happened to stumble across these discussions on standardizing .conf while trying to figure out why my site-wide config was getting ignored.

[pfmoore]

I'd be inclined to change the docs to match the code (i.e. change the docs for the site location to say %PROGRAMDATA%\pip\pip.ini. That's consistent and a minimal change.

I don't see much benefit switching the extension. .ini is common on Windows, whereas .conf is not. And it's what's been used for a while now, so why change?

[kpersohn]

Devil's Advocate: I think someone made an argument for .conf to enable platform-agnostic virtualenvs.

I like a simple change to the docs, though. That's easy enough.

[Ivoz]

I'd advocate for while not minding what extension is used, make it the same regardless of operating systems. They can all open text files. pip.*s are for technical users to read and write. Having to change (and know) the extension depending on what operating system you're using is simply a bug bear.

[pfmoore]

My concern is that the file has been pip.ini for a long time now (since 1.4 at least) it's just the location that has changed. I'm not against changing but it's a backward compatibility break.

Outside of tools like tox (which presumably already copes with the ini vs conf issue, if it needs to) how many cases are there where something will need to manage virtualenvs in a cross-platform manner?

[dstufft]

It probably doesn't hurt to support both on both systems (if we don't already). If we support both, then it just comes down to which do we document.

[piotr-dobrogost]

I really don't get hiding features by not documenting them. What's wrong with either supporting something (with proper docs) or not supporting and removing from code and docs? In case there's change in behavior (going from .ini to .conf on Windows here) transition period with warning is all that's needed. I agree with @LVoz that it would be better to be consistent across platforms.

[pfmoore]

Agreed - we should document what we support. Personally, I'm happy with the status quo, but would be willing to switch if people feel it's worth making the change. Supporting both seems like pointless overhead, though (we need to document the order they are used in, deal with bugs from people who didn't read the docs properly and messed up, etc...)

[pradyunsg]

I don't think anyone's asking for this anymore... closing!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.