Open GoogleCodeExporter opened 9 years ago
Also FWIW: several Windows releases (XP, Vista, Server 2008b) cannot handle
nested environment variables [http://support.microsoft.com/kb/911089]. This
became an issue when I defined %WINPYDIR% as the python install path, then
created %WINPYPATH% with the proper folders (rel. to %WINPYDIR%) and tried
adding %WINPYPATH% to %PATH%.
Based on that headache, the most flexible and portable way to 'Register' with
PATH would seem to be to add a new env var %WINPYDIR%->[python install dir],
then add the req'd folders to %PATH% itself (rel. to %WINPYDIR% of course).
[Which is basically what happens in env.bat]
Original comment by wsu...@gmail.com
on 3 Apr 2013 at 12:10
The registration do not add anything to environment variables because it
shouldn't be necessary when using WinPython launchers (due to the fact that
it's a *portable* application). As a consequence, running 'python.exe' in a
standard command window won't work: it will only work from a WinPython command
window. Only the WinPython command window (or scripts\env.bat, which is
basically the same thing) will configure your system completely.
What you suggest is of course doable but would require some coding tasks:
* Registering WinPython:
* Add %WINPYDIR% environment variable
* Add required folders to %PATH% with paths relatives to %WINPYDIR%
* Unregistering WinPython:
* Remove %WINPYDIR% environment variable
* Remove all folders containing %WINPYDIR% in %PATH%
What do you think about it?
Original comment by pierre.raybaut
on 21 Apr 2013 at 8:08
I think you understand what I'm looking for. I appreciate it's a portable
application but since the status bar help message for Advanced > Register
distribution... says 'Register file extensions, icons, and context menu' it
seems sensible to me to add it to the system path as well.
As far as adding it to the path, I believe the PATH env. var needs to be
modified through the registry in order to make it stick. It could be added to
just a user's PATH or the system PATH by using HKEY_USER versus HKLM (I think).
I don't know which is cleaner for the user:
1) Add a PYDIR env. var pointing to the python distro within WinPython, then
add the necessary paths to PATH with a PYDIR substitute or
2) Add a WINPYPATH env. var with all the required paths hardcoded to the
internal python distro and add this new env. var to the path
It is necessary to restrict nesting to one level for compatibility with, for
example, XP machines.
I imagine the reverse procedure for unregistering might be a bit more tedious.
There does not appear to be a way to unregister WinPython at all at the moment
though. Option 2 above would be easier to clean up IMO, especially if the env.
var name was specific to a particular WinPython version. Then multiple
WinPythons could un/re-register without affecting one another by
adding/removing their specific env. var from PATH.
Since not all users may want WinPython on their PATH, perhaps there should be
new menu items: Advanced > Add python to user path, Advanced > Add python to
system path
Original comment by wsu...@gmail.com
on 22 Apr 2013 at 5:33
Option 2 sounds good to me too. Excellent suggestion.
As for modifying the PATH environment variable in a persistent way, it may be
done using the following code for example:
https://code.google.com/p/spyderlib/source/browse/spyderlib/utils/environ.py#75
I'll implement this feature in next release, as soon as I can.
Original comment by pierre.raybaut
on 22 Apr 2013 at 6:54
Thank you for accepting my suggestion. And for providing the example link too.
Original comment by wsu...@gmail.com
on 22 Apr 2013 at 11:04
Original comment by pierre.raybaut
on 1 May 2013 at 4:18
Started with revision 4c7a90c40f0a.
Original comment by pierre.raybaut
on 1 May 2013 at 4:20
Original comment by pierre.raybaut
on 8 May 2013 at 7:43
I see the changes to `/winpython/utils.py` but don't see corresponding changes
to `register()` in `/winpython/associate.py`. Would that be the place to start
to get this feature working?
Original comment by wsu...@gmail.com
on 1 Jul 2014 at 9:26
Original issue reported on code.google.com by
wsu...@gmail.com
on 2 Apr 2013 at 9:23