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
Move .idlerc to %APPDATA%\IDLE on Windows #68953
Comments
IDLE shouldn't pollute user's home directory on Windows, standard location for config files is %APPDATA%\<App>, which resolves to C:\Users\<user>\AppData\Roaming\<App> in Vista upwards and somewhere in Documents and Settings under XP. |
On Windows, using the shell's Known Folders API is preferred. For Python 3.6+, an extension module could wrap SHGetKnownFolderPath and provide a dict of KNOWNFOLDERID values such as FOLDERID_RoamingAppData. On Linux, there's the XDG Base Directory Specification. The application directory is created in one or more of the following directories {default in brackets}: $XDG_CONFIG_HOME { What about Mac OS X? |
Mac Developer Library mentions Library/Application Support/<App> as a preferred directory to store configuration files for an application, gotten via a call to NSSearchPathForDirectoriesInDomains or NSFileManager with NSApplicationSupportDirectory path key and either NSLocalDomainMask domain (for all users) or NSUserDomainMask domain (for current user). |
See also bpo-7175, although I think that is more about low-level Python configuration, rather than application-level configuration like Idle. |
Two negative factors.
|
You can type in '%APPDATA%' in the path bar, run dialog, or even start menu, and it will take you to the current user's Application Data folder. It works from XP upwards.
Yes, I imagine that's a bigger issue. The installer could, however, check whether there is currently an .idle directory in user folder and copy the settings over. |
And if the older version is still present, as 2.7 will be for years, copy back to .idlerc. To me, having two copies of the directory, one in the 'wrong' place, is worse than one copy in the wrong place. |
Further to Terry's backwards compatibility issues (also discussed in bpo-8231). Storing things in the "correct" location (%APPDATA% on Windows, and Application Support on OS X) would presumably be the "right" thing to do if backwards compatibility weren't an issue. If "APPDATA" is the "correct" place, and "HOME" is what we've been using now, consider a solution like this:
This handles the common cases of existing user upgrading to new scheme (things stay stored in old location), new user upgrading to newer versions in future (things go in new place), but fails on the case of user starts with new version and then later uses an older version (results in two separate preferences, one used by newer versions, one used by older). I think it's a legitimate question as to whether that latter case is common enough or problematic enough to worry about it (given "fails" doesn't break anything). |
I do not consider the presence of .idlec in $HOME on Windows to be a problem in itself. There are numerous applications, unix-derived and otherwise, that do the same with config files. Very few, if any, have the issue of sharing between multiple simultaneous versions. Installing a new versions deletes the old. Many do not have the issue of users needing to edit the files. These would be better candidates for making the switch. Under current circumstances, I reject the proposal. However, since I hope circumstances change, I am closing this as 'postponed' rather than 'rejected'. What I hope we can do, to make me *want* to re-open this.
Each of these has benefits in itself, and the net effect would be that most everyone would only need to run the latest IDLE they have and not need to touch the .cfg files. At this point, we would want to change the format and put them in a different (and less accessible) place anyway. |
On Windows, how about creating a junction (_winapi.CreateJunction in 3.5, or the shell's mklink /j) from ~\.idlerc to %APPDATA%\idle? If ~\.idlerc already exists, it could be moved to %APPDATA%\idle before creating the junction. New code would directly use %APPDATA%\idle, but old code would continue to use ~\.idlerc. Creating junctions requires no special privilege, but IDLE would need write access to the user's home directory. If write access is denied, at least newer IDLE versions that use %APPDATA% would work. On Linux, a symbolic link could be created from ~/.idlerc to [$XDG_CONFIG_HOME|~/.config]/idle. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: