Add python.exe to PATH environment variable
Hi, I've always found it strange that Python Windows installers never managed to add the python executable to the PATH environment variable. Are there plans for adding such a thing? Thanks in advance --- Giampaolo http://code.google.com/p/pyftpdlib/
Hello, Giampaolo Rodola' wrote:
Hi, I've always found it strange that Python Windows installers never managed to add the python executable to the PATH environment variable. Are there plans for adding such a thing?
I don't think so. See the discussion of http://bugs.python.org/issue3561 -- Amaury Forgeot d'Arc
On Tue, Sep 2, 2008 at 1:38 PM, Amaury Forgeot d'Arc <amauryfa@gmail.com>wrote:
Hello,
Giampaolo Rodola' wrote:
Hi, I've always found it strange that Python Windows installers never managed to add the python executable to the PATH environment variable.
+1 At this point, as far as I know, changing the PATH variable manually under Windows is the most convenient way to be able to work correctly with Python.
Are there plans for adding such a thing?
I don't think so. See the discussion of http://bugs.python.org/issue3561
I don't understand why it is closed/wontfix though. In the tracker Martin said: """ The very end-user related aspects of it need to be discussed on python-dev (perhaps taking a poll whether this is desirable, whether it should be optional, and if so, what the default should be) """ So I'd like to give my opinion here about this, because I've had this problem while writing a book about Python. (a book that is for people that use Python on *any* platform bien sûr, not only Linux) For me, the Windows installer does not work properly: I cannot open a console and run Python right away. I don't care about the technical complexity of setting it up automatically : I simply think it is wrong not to be able to run the interpreter the same way on Windows and Linux/Mac OS. You may end up having to deal with it in your documentation. Look at all the documentation out there. For instance Pylons: http://wiki.pylonshq.com/display/pylonsdocs/Installing+Pylons -> there's a small note on that page "All windows users also should read the section Post install tweaks for Windows<http://wiki.pylonshq.com/display/pylonsdocs/Windows+Notes>after installation" -> windows users need to go there : http://wiki.pylonshq.com/display/pylonsdocs/Windows+Notes Why do we have to take care about that ? Python installers should. A lot of package out there create console scripts (buildout, sphinx, rst2html, etc..) that lives in /Script, and are not reachable in Windows unless the PATH is changed. So I don't see any good reason (besides the technical complexity) to add it to the Windows installer. Or at least do something that will let us run Python and third-party scripts from the command line even if it is done with PATH. So I would love to see this ticket open again; I personnaly would be in favor of an automatic change of PATH by the installer. My 2 cents Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
Tarek Ziadé wrote:
So I don't see any good reason (besides the technical complexity)
Unless and until someone is able and willing to deal with the technical complexity, that would seem to be a sufficient reason.
to [not, I presume] add it to the Windows installer.
So I would love to see this ticket open again; I personnaly would be in favor of an automatic change of PATH by the installer.
Martin said he would discuss a patch when there is a patch to discuss. He feels strongly about there being a clean uninstall, including PATH restoration if it is changed. The problem is that a) the Window's way to run user apps is via icons and menus and that b) the old DOS path/command way, based on Unix, has been neglected. An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory. Then one could enter
python or >Scripts/goforit without chdir-ing to the Python directory first. The background could even be set to green, for instance, to differentiate it from the standard Command Prompt window.
Terry Jan Reedy
Terry Reedy <tjreedy <at> udel.edu> writes:
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory.
The reason for adding the directory to the PATH is for it to be recognized in any command prompt, not only the Python-dedicated command prompt shortcut. Otherwise, the minute another project decides to do the same thing (provide a custom command prompt shortcut rather than add its own directory to the PATH), the user experience becomes very tedious.
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory.
The reason for adding the directory to the PATH is for it to be recognized in any command prompt, not only the Python-dedicated command prompt shortcut.
Actually, that is *your* reason for adding it to the global path. But adding it to the global path has many more side-effects than just allowing 'python' to work at the command-prompt - every running program of yours, even those not related to command-prompts or Python, has the opportunity to get confused about the files that might appear in those directories.
Otherwise, the minute another project decides to do the same thing (provide a custom command prompt shortcut rather than add its own directory to the PATH), the user experience becomes very tedious.
The problem is that if every installer offers to update the path, it gets quite tedious making corrections and tweaks (eg, I'm never offered the option of *where* on the path to install it, and sometimes this is very important!) FWIW, my opinion is similar to how I read Martin's - that if a suitable, safe patch that cleanly uninstalls can be found, it should be included, but disabled by default. Personally I'd never use it. Cheers, Mark
Mark Hammond <mhammond <at> skippinet.com.au> writes:
The reason for adding the directory to the PATH is for it to be recognized in any command prompt, not only the Python-dedicated command prompt shortcut.
Actually, that is *your* reason for adding it to the global path.
What do you mean? Are there other practical reasons than the above for adding the directory to the PATH?
But adding it to the global path has many more side-effects than just allowing 'python' to work at the command-prompt - every running program of yours, even those not related to command-prompts or Python, has the opportunity to get confused about the files that might appear in those directories.
What do you mean by "get confused about the files that might appear in those directories"? Unless those running programs of mine deliberately crawl through the PATH (in which case I assume they have a good reason of doing so), I don't understand in what way they would "get confused". But I admit I'm not an expert Windows user. Regards Antoine.
Mark Hammond <mhammond <at> skippinet.com.au> writes:
The reason for adding the directory to the PATH is for it to be recognized in any command prompt, not only the Python-dedicated command prompt shortcut.
Actually, that is *your* reason for adding it to the global path.
What do you mean? Are there other practical reasons than the above for adding the directory to the PATH?
My point was that it applies to much more than command-prompts. There are pratical reasons for adding entries to your global PATH that don't include the ability to run executables at the command-line.
What do you mean by "get confused about the files that might appear in those directories"?
I mean that many Windows use the PATH, and as such, may fail if a new directory is added to the PATH that contains a DLL they indirectly use. I don't need any program *except* a command-prompt to be able to locate a 'python.exe', so I arrange for only command-prompts to have their PATH setup that way. If I *did* expect other programs to be able to find a 'python.exe', I'm not sure I'd want to risk that installing a later version of Python will change what Python is found. Cheers, Mark
Mark Hammond <mhammond <at> skippinet.com.au> writes:
I mean that many Windows use the PATH, and as such, may fail if a new directory is added to the PATH that contains a DLL they indirectly use.
Then it's just a matter of not putting any DLLs in those directories, isn't it?
If I *did* expect other programs to be able to find a 'python.exe', I'm not sure I'd want to risk that installing a later version of Python will change what Python is found.
Most Linux distributions solve that by installing binaries named /usr/bin/python2.4, /usr/bin/python2.5, etc., and making /usr/bin/python a symlink to one of those. Thus if a program relies on particular Python version, it can just use a specific executable rather than a generic one.
I mean that many Windows use the PATH, and as such, may fail if a new directory is added to the PATH that contains a DLL they indirectly use.
Then it's just a matter of not putting any DLLs in those directories, isn't it?
A. It's not just DLLs. Any program invoking CreateProcess might pick up the Python executable. This might be confusing if the program would previously pick up a different Python installation. B. I don't think this can work: we *must* install DLLs into the Python directory - at least pythonxy.dll (at least the way Python is currently build - maybe SxS would allow to place it elsewhere). I *think* we also need to place the CRT manifest in the directory; not sure what consequences this has.
Most Linux distributions solve that by installing binaries named /usr/bin/python2.4, /usr/bin/python2.5, etc., and making /usr/bin/python a symlink to one of those. Thus if a program relies on particular Python version, it can just use a specific executable rather than a generic one.
Unfortunately, symlinks are not available on Windows. OTOH, other things *are* available, such as registered extensions. For example, you don't need python on PATH to start a Python script; just invoking the .py file will find the Python interpreter from the registry. I don't think it is wise to apply Unix solutions to Windows problems. Regards, Martin
Martin v. Löwis wrote:
OTOH, other things *are* available, such as registered extensions. For example, you don't need python on PATH to start a Python script; just invoking the .py file will find the Python interpreter from the registry.
But then you don't get to pass arguments to the program, get to see the output before the window disappears, etc. -- Greg
Greg Ewing wrote:
Martin v. Löwis wrote:
OTOH, other things *are* available, such as registered extensions. For example, you don't need python on PATH to start a Python script; just invoking the .py file will find the Python interpreter from the registry.
But then you don't get to pass arguments to the program, get to see the output before the window disappears, etc.
I believe you are confusing the command-line PATHEXT mechanism with the Explorer/registry execution mechanism: C:\Users\sholden\Documents\dyjr>python 'python' is not recognized as an internal or external command, operable program or batch file. C:\Users\sholden\Documents\dyjr>manage.py Type 'manage.py help' for usage. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
FWIW, my opinion is similar to how I read Martin's - that if a suitable, safe patch that cleanly uninstalls can be found, it should be included, but disabled by default. Personally I'd never use it.
That's my view also (less strict now; I previously would have rejected it outright, as I didn't consider that it might be optional and off by default). Regards, Martin
On 2008-09-02 23:14, Terry Reedy wrote:
Tarek Ziadé wrote:
So I don't see any good reason (besides the technical complexity)
Unless and until someone is able and willing to deal with the technical complexity, that would seem to be a sufficient reason.
to [not, I presume] add it to the Windows installer.
So I would love to see this ticket open again; I personnaly would be in favor of an automatic change of PATH by the installer.
Martin said he would discuss a patch when there is a patch to discuss. He feels strongly about there being a clean uninstall, including PATH restoration if it is changed.
The problem is that a) the Window's way to run user apps is via icons and menus and that b) the old DOS path/command way, based on Unix, has been neglected.
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory. Then one could enter
python or >Scripts/goforit without chdir-ing to the Python directory first. The background could even be set to green, for instance, to differentiate it from the standard Command Prompt window.
There already is a menu entry that starts the Python interpreter on Windows, so why not use that ? Also .py files are automatically associated with the last installed Python interpreter, so the double-clicking on .py files works and is probably the most common way of starting a Python file on Windows. Adding paths to the PATH variable is not easy on Windows, esp. if you want to support multiple Windows versions. The global PATH settings are not read from autoexec.bat anymore (only once at boot time). Instead those environment variables are managed via the registry. See e.g. http://agiletesting.blogspot.com/2005/06/handling-path-windows-registry-valu... for how to setup PATH to your liking using Python. The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ? BTW: Adding the Python dir to the PATH per default would cause problems for users who regularly have multiple different Python installations on a machine. If this is done, it should be an install option and not forced. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 03 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an entry corresponding to the Python installation that's being uninstalled, then it's not going to work once the installation is gone, so removing it isn't going to do much harm. In any case, the danger could be reduced by picking some distinctive name for a new environment variable that a user isn't likely to come up with on their own, such as __AUTOPYEXECDIR__, setting that to the Python directory, and adding it to PATH. The uninstaller can then be fairly selective about what it removes.
BTW: Adding the Python dir to the PATH per default would cause problems for users who regularly have multiple different Python installations on a machine.
No more problem than having it set the file associations, as far as I can see. If you have multiple Pythons, you're going to have to be explicit about which one you want from the command shell anyway, and not rely on a PATH setting.
If this is done, it should be an install option and not forced.
Certainly it should be an option. I'm not sure about having it disabled by default, though, since naive users are the ones that stand to benefit most from it, yet they're least likely to know that they need to turn it on. -- Greg
On 2008-09-03 04:12, Greg Ewing wrote:
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an entry corresponding to the Python installation that's being uninstalled, then it's not going to work once the installation is gone, so removing it isn't going to do much harm.
You have a point there :-)
In any case, the danger could be reduced by picking some distinctive name for a new environment variable that a user isn't likely to come up with on their own, such as __AUTOPYEXECDIR__, setting that to the Python directory, and adding it to PATH. The uninstaller can then be fairly selective about what it removes.
BTW: Adding the Python dir to the PATH per default would cause problems for users who regularly have multiple different Python installations on a machine.
No more problem than having it set the file associations, as far as I can see. If you have multiple Pythons, you're going to have to be explicit about which one you want from the command shell anyway, and not rely on a PATH setting.
True, I have configured Windows to provide several "Open with Python x.x" in order to have more flexibility. However, always having the latest version on PATH is not an option either, since e.g. I wouldn't want all .py scripts to be run by Python 3.0 just because I installed it for testing purposes.
If this is done, it should be an install option and not forced.
Certainly it should be an option. I'm not sure about having it disabled by default, though, since naive users are the ones that stand to benefit most from it, yet they're least likely to know that they need to turn it on.
In my experience, Windows apps seem to be moving aways from cluttering up PATH and include each and every single app dir to it. Instead, if they bother at all, they simply place a .bat or small .exe into the Window system dir (which already is on PATH). Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 03 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
M.-A. Lemburg wrote:
On 2008-09-03 04:12, Greg Ewing wrote:
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ? Is that really much of an issue? If the PATH contains an entry corresponding to the Python installation that's being uninstalled, then it's not going to work once the installation is gone, so removing it isn't going to do much harm.
You have a point there :-)
Unless you install it with the "add to path" option, deinstall it, and the reinstall without the "add to path" option. That is, assuming the install directory is the same every time. Not that I think this is common, except in testing scenarios.
Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a decision on whether or not to delete the file. But I agree that managing a single batch file is easier than dealing with the PATH variable, and has fewer side effects (finding DLL's, etc.). Eric.
Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a decision on whether or not to delete the file.
If this is done the batch file should be named "python25.bat" or so depending on the version. -- Thanks, Thomas
On Wed, Sep 3, 2008 at 3:10 PM, Thomas Heller <theller@ctypes.org> wrote:
Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\.
If this is done the batch file should be named "python25.bat" or so depending on the version.
Instead of having a .bat file we could have a helper program that sets the appropriate PATH and then runs cmd.exe. It would be available from the start menu. This way, we wouldn't clutter C:\Windows\System\ with batch files.
On 03/09/2008, Thomas Heller <theller@ctypes.org> wrote:
Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a decision on whether or not to delete the file.
If this is done the batch file should be named "python25.bat" or so depending on the version.
Bat files don't work when called from another bat file. This hits me regularly, when people supply wrapper bat files. Example: myscript.bat: @echo off do some stuff python my_py_script.py do some more stuff If "python" is a bat file, "do some more stuff" will never get run (you need to say "call python" to allow bat files to nest). -1 (or stronger!) on a bat file. If it goes in anyway, make it optional and off by default. The confusion and wasted time caused by bat files "stopping" part way through is FAR worse than that caused by having to manage PATH for yourself. Paul. PS If anyone knows a *good* way of writing wrapper scripts on Windows which doesn't suffer from the bat file nesting problem above, please let me (and the rest of the world!) know!
Paul Moore wrote:
On 03/09/2008, Thomas Heller <theller@ctypes.org> wrote:
Perhaps we could have an option to place a "python.bat" into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a decision on whether or not to delete the file. If this is done the batch file should be named "python25.bat" or so depending on the version.
Bat files don't work when called from another bat file.
You can use "CALL" within one batch file to chain another, returning afterwards to the first. But this is obviously not the most transparent thing on earth! TJG
On 03/09/2008, Tim Golden <mail@timgolden.me.uk> wrote:
You can use "CALL" within one batch file to chain another, returning afterwards to the first.
Correct. Sorry, I forgot to mention that.
But this is obviously not the most transparent thing on earth!
Indeed - and it certainly isn't a "wrapper" in the sense that I would use the word (which is more in the sense of "drop-in replacement"). Paul.
Tim Golden wrote:
You can use "CALL" within one batch file to chain another, returning afterwards to the first.
You need to know that what you're calling is a bat file to have the foresight to do that, though. I can imagine people not expecting "python" to be a bat file. Instead of a bat file, maybe generate a small exe that does the job? -- Greg
Paul Moore schrieb:
Bat files don't work when called from another bat file. This hits me regularly, when people supply wrapper bat files. Example:
myscript.bat: @echo off do some stuff python my_py_script.py do some more stuff
If "python" is a bat file, "do some more stuff" will never get run (you need to say "call python" to allow bat files to nest).
-1 (or stronger!) on a bat file.
If it goes in anyway, make it optional and off by default. The confusion and wasted time caused by bat files "stopping" part way through is FAR worse than that caused by having to manage PATH for yourself.
Paul.
PS If anyone knows a *good* way of writing wrapper scripts on Windows which doesn't suffer from the bat file nesting problem above, please let me (and the rest of the world!) know!
/F's exemaker and Philip's setuptools script wrapper come to mind. -- Thanks, Thomas
On Wed, Sep 3, 2008 at 3:46 PM, Paul Moore <p.f.moore@gmail.com> wrote:
PS If anyone knows a *good* way of writing wrapper scripts on Windows which doesn't suffer from the bat file nesting problem above, please let me (and the rest of the world!) know!
You can use setuptools console scripts, they are added in the Scripts directory by default, but this is optional see : http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation We write all our wrappers with it and... hum.. add /Scripts to PATH under Windows :D Tarek
M.-A. Lemburg wrote:
However, always having the latest version on PATH is not an option either, since e.g. I wouldn't want all .py scripts to be run by Python 3.0 just because I installed it for testing purposes.
Keep in mind that the normal installation process on unix *does* make "python" refer to the most recently installed version, at least for 2.x, and it's not considered a problem there. In the case of 3.0, didn't we decide not to do that? -- Greg
M.-A. Lemburg wrote:
On 2008-09-02 23:14, Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory. Then one could enter
python or >Scripts/goforit without chdir-ing to the Python directory first. The background could even be set to green, for instance, to differentiate it from the standard Command Prompt window.
There already is a menu entry that starts the Python interpreter on Windows, so why not use that ?
I do and will*, but some people want to start a command window and then type 'python' just like they would on *nix (*without having to explicitly change to the Python directory*), or be able to run stuff in a subdirectory of the Python directory. So I suggested an alternative to the request for PATH manipulation that could easily be done now. * I recently *did* run Python from a command prompt so I could make sure it was running 'cmd.exe /u' and try changing the code page (but this is another story), but I simply moved to the directory first. For me, not a big deal. tjr
Terry Reedy wrote:
M.-A. Lemburg wrote:
On 2008-09-02 23:14, Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory. Then one could enter
python or >Scripts/goforit without chdir-ing to the Python directory first. The background could even be set to green, for instance, to differentiate it from the standard Command Prompt window.
There already is a menu entry that starts the Python interpreter on Windows, so why not use that ?
I do and will*, but some people want to start a command window and then type 'python' just like they would on *nix (*without having to explicitly change to the Python directory*), or be able to run stuff in a subdirectory of the Python directory. So I suggested an alternative to the request for PATH manipulation that could easily be done now.
A cleaner (though still dirty) way to achieve this would be to add a link to the appropriate "python.exe" in a directory already on the path such as c:\Windows\system32
* I recently *did* run Python from a command prompt so I could make sure it was running 'cmd.exe /u' and try changing the code page (but this is another story), but I simply moved to the directory first. For me, not a big deal.
My own solution, on systems where I haven't bothered to add \python25 and python25\Scripts to the PATH, is to simply use \python25\python With tab expansion enabled by default it's easy enough. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
A cleaner (though still dirty) way to achieve this would be to add a link to the appropriate "python.exe" in a directory already on the path such as c:\Windows\system32
That would be fairly easy to implement. I suppose pythonw.exe wouldn't need the same treatment, as people won't invoke it manually. I guess that option wouldn't be available to non-admin users, though.
My own solution, on systems where I haven't bothered to add \python25 and python25\Scripts to the PATH, is to simply use
\python25\python
With tab expansion enabled by default it's easy enough.
Same for me. That's why I like Python being installed in the root directory (also a common complaint - why doesn't it install into the Programs Files folder?) Regards, Martin
On 03 sep 2008 at 00:50:13, M.-A. Lemburg <mal@egenix.com> wrote:
There already is a menu entry that starts the Python interpreter on Windows, so why not use that ?
Because i need to start Python from folders which have files that define a specific "environment". I have several servers and applications that develop and test this way.
Also .py files are automatically associated with the last installed Python interpreter, so the double-clicking on .py files works and is probably the most common way of starting a Python file on Windows.
99% of time I run Python from a command prompt (on specific directories). I use the default menu entry only when I have to play with Python to test some pieces of code.
Adding paths to the PATH variable is not easy on Windows, esp. if you want to support multiple Windows versions. The global PATH settings are not read from autoexec.bat anymore (only once at boot time). Instead those environment variables are managed via the registry.
See e.g.
http://agiletesting.blogspot.com/2005/06/handling-path-windows-registry-valu...
for how to setup PATH to your liking using Python.
The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ?
BTW: Adding the Python dir to the PATH per default would cause problems for users who regularly have multiple different Python installations on a machine. If this is done, it should be an install option and not forced.
Let the user to decide to update or not the PATH envar by marking a chechbox in the setup process, displaying that doing that the changes will NOT be reverted when uninstalling it. Cheers, Cesare
On 2008-09-03 10:15, Cesare Di Mauro wrote:
On 03 sep 2008 at 00:50:13, M.-A. Lemburg <mal@egenix.com> wrote:
There already is a menu entry that starts the Python interpreter on Windows, so why not use that ?
Because i need to start Python from folders which have files that define a specific "environment".
I have several servers and applications that develop and test this way.
Same here, but I usually have a env.bat that sets up whatever environment I need (including the required Python version) and run that when opening a prompt to work on a particular project.
Also .py files are automatically associated with the last installed Python interpreter, so the double-clicking on .py files works and is probably the most common way of starting a Python file on Windows.
99% of time I run Python from a command prompt (on specific directories).
I use the default menu entry only when I have to play with Python to test some pieces of code.
IMHO, the only point of having the installer do this for the user is for the case where the user does not know how to manipulate PATH on Windows, but still wants to use the command line to access it directly. How many users would fit that category ?
Adding paths to the PATH variable is not easy on Windows, esp. if you want to support multiple Windows versions. The global PATH settings are not read from autoexec.bat anymore (only once at boot time). Instead those environment variables are managed via the registry.
See e.g.
http://agiletesting.blogspot.com/2005/06/handling-path-windows-registry-valu...
for how to setup PATH to your liking using Python.
The problem is: how to undo those changes without accidentally undoing an explicit change made by the user ?
BTW: Adding the Python dir to the PATH per default would cause problems for users who regularly have multiple different Python installations on a machine. If this is done, it should be an install option and not forced.
Let the user to decide to update or not the PATH envar by marking a chechbox in the setup process, displaying that doing that the changes will NOT be reverted when uninstalling it.
Hmm, I don't think that's a good way to go about this. The uninstall should undo all changes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 03 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
On 03 Sep 2008 at 13:34:18, M.-A. Lemburg <mal@egenix.com> wrote:
Same here, but I usually have a env.bat that sets up whatever environment I need (including the required Python version) and run that when opening a prompt to work on a particular project.
IMHO, the only point of having the installer do this for the user is for the case where the user does not know how to manipulate PATH on Windows, but still wants to use the command line to access it directly.
How many users would fit that category ?
I don't know, but when you are working with just one python instance, there's no need to use batch files neither to care about what PATH says: it's always the right one instance that will be picked. :)
Let the user to decide to update or not the PATH envar by marking a chechbox in the setup process, displaying that doing that the changes will NOT be reverted when uninstalling it.
Hmm, I don't think that's a good way to go about this. The uninstall should undo all changes.
The problem here is that uninstaller doesn't work this way. May be an external program called by the uninstaller can take care of this, removing what was added to PATH. Cesare
Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the Start Menu a Command Prompt shortcut, call it Command Window or something, that starts in the Python directory.
That doesn't seem very satisfactory, because the user is going to want to work in the directory containing his script, or the data he wants to run the script on. A better way would be to start a command process with the Python directory added to PATH just for that process. How easy would that be to do on Windows? Do environment variables get inherited by child processes the way they do on Unix? -- Greg
Giampaolo Rodola' wrote:
Hi, I've always found it strange that Python Windows installers never managed to add the python executable to the PATH environment variable. Are there plans for adding such a thing?
No, but I've added a little helper script several months ago. It adds the Python and Script paths to %PATH%. See Tools/Scripts/win_add2path.py Christian
participants (17)
-
"Martin v. Löwis" -
Amaury Forgeot d'Arc -
Antoine Pitrou -
Cesare Di Mauro -
Christian Heimes -
Eric Smith -
Giampaolo Rodola' -
Greg Ewing -
karim hamidou -
M.-A. Lemburg -
Mark Hammond -
Paul Moore -
Steve Holden -
Tarek Ziadé -
Terry Reedy -
Thomas Heller -
Tim Golden