Why does Python never add itself to the Windows path?

[Ben Sizer]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default? I just
rediscovered this today when trying to run one of the Turbogears
scripts, but this has puzzled me for years now.

 

[vbgunz]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default? I just
rediscovered this today when trying to run one of the Turbogears
scripts, but this has puzzled me for years now.

excellent question

 

[Eric_Dexter]

I don't seem to have any problem running python programs regardless of
where they are. My platform is windows xp and I have run both 2.4 and
2.5 more details about what version of windows you are running might be
helpfull

https://sourceforge.net/project/showfiles.php?group_id=156455&package_id=174569

 

[MC]

Hi!

+1

 

[Ross Ridge]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable.

Personally, I hate Windows applications that add themselves to the
PATH. So much crap gets put in there that I don't even use the default
system PATH and just set my own explicitly.

Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation.

If you're installing multiple versions of Python on one machine you're
going to have to do this anyways to ensure the version of Python you
want first in the path actually is first.

No such problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu.

Linux distributions normally install themselves somewhere that's
normally in the path already. I suppose you can do the same thing on
Windows if you want, just choose to install Python into directory
that's already in your path. Though installing to something like
C:\WINDOWS\SYSTEM32 is probably not a good idea.

Ross Ridge

 

[Ben Sizer]

I don't seem to have any problem running python programs regardless of
where they are. My platform is windows xp and I have run both 2.4 and
2.5 more details about what version of windows you are running might be
helpfull

I don't think the Windows version is relevant. I did point out that
this happens across different incarnations of Windows (98SE and XP the
2 I have on hand to test), and that the problem wasn't specifically
about "running python programs". Basically if you go to a command
prompt and type "python", it won't do anything on a plain Python
install on Windows. Try it on Linux, and probably Mac too, and it'll do
something useful.

Similarly, if you install a Python package that adds to the scripts
directory, you can typically expect to run those scripts from the
command line without having to use the full path - not on Windows.

 

[Ben Sizer]

Personally, I hate Windows applications that add themselves to the
PATH. So much crap gets put in there that I don't even use the default
system PATH and just set my own explicitly.

Personally I hate programs that ask to be installed to the root folder
of my hard drive, but Python suggests that as a default too.

In an ideal world, Python should operate pretty much the same across
all platforms. Unfortunately, as it stands, you need to have different
instructions for running things on Windows. eg. The standard "python
setup.py install" invocation isn't going to do a damn thing unless
you've fixed up the path beforehand. The same goes for "python
ez_setup.py", another common favourite. The scripts directory is
important too: TurboGears installs a "tg-admin" script which you're
supposed to run from your project's directory: which on Windows means
you need to type something like "c:\python24\scripts\tg-admin" each
time. Half of the people who develop on Mac and Linux don't realise or
acknowledge this. and so the instructions for using their packages
don't work for the average person new to Python who probably just ran
the Windows installer program and thought that would suffice.

Linux distributions normally install themselves somewhere that's
normally in the path already. I suppose you can do the same thing on
Windows if you want, just choose to install Python into directory
that's already in your path. Though installing to something like
C:\WINDOWS\SYSTEM32 is probably not a good idea.

The Windows way is typically to install things in Program Files and
then point things there as necessary. Installing it the Linux way would
just cause a different set of problems. Adding it to the PATH variable
is not going to cause problems for the vast majority of people, and
it's far easier to edit up the PATH to remove an entry you don't want,
than to move an installed program from one place to another.

 

[WaterWalk]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default? I just
rediscovered this today when trying to run one of the Turbogears
scripts, but this has puzzled me for years now.

Well, after Python is installed on a Windows platform, files with
extention ".py" or ".pyw" are automatically associated with python or
pythonw. If a python script is double-clicked or input something like
"sth.py" in the "cmd" box, the python interpreter is automatically
called. I don't see any proplem or inconvenience with this.

 

[Dustan]

Well, after Python is installed on a Windows platform, files with
extention ".py" or ".pyw" are automatically associated with python or
pythonw. If a python script is double-clicked or input something like
"sth.py" in the "cmd" box, the python interpreter is automatically
called. I don't see any proplem or inconvenience with this.

In the command line, entering "python" does not run the python
interpreter (unless you modify the settings yourself).

 

[robert]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default? I just
rediscovered this today when trying to run one of the Turbogears
scripts, but this has puzzled me for years now.

That would put together a great mix-up if app installations add to the PATH. Think of multiple installations etc.
( Note: this is also _NOT_ done on *nix - just a sym link is possibly put into /usr/local/bin or so )

To have something similar on Win I have a C:\bin folder where I put all my small .exe's / installations and all the start vectors (.exe, .bat's....).

The python.exe on Win is very small and just loads the pythonXX.dll. It also finds the right default DLL due to the version engraved in python.exe.
Thus I just copy the small python.exe from my favorite/default Python installation (2.3) into my C:\bin.
Thats probably next to what you obviously want - a "default link".
The Test&Fun-Pythons ( ... 2.2 2.4 2.5 2.6 ) - I have them renamed as e.g. python25.exe also in C:\bin . I make similar links on *nix also.

Perhaps in the future the Python Windows installer should create such pythonXX.exe "links" and maybe even a default python.exe (upon Checkbox in Installer!) into the Windows\system32 ?


Robert

 

[Guest]

Personally, I hate Windows applications that add themselves to the
PATH. So much crap gets put in there that I don't even use the default
system PATH and just set my own explicitly.

Agreed. A good Windows application minimizes its footprint, only
adding registry keys, environment variables, system tray icons,
services, shell extensions, etc, etc, when absolutely necessary.
Python is such an application.

But on the other hand, I use Python on the Windows command line all the
time. Having to manually set PATH for each machine I use Python on is
a minor annoyance.

One solution would be an optional feature on the MSI to prepend the
install directory to PATH. In fact, this is what ActivePython does.
Any reason why the official Python distribution shouldn't?

--Ben Cartwright

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default?

For several reasons:
1. Python can be used just fine without being on PATH. Python
scripts run fine both when double-clicked and when invoked in
the command line, and if you want to use an interactive
interpreter, you can find it readily on the Start menu.
2. Many windows users (including myself) dislike setup routines that
manipulate PATH. I believe that the PATH environment variable
is "owned" by the user; if Python is to be found in PATH, it
should rather be installed to a directory that is known to live
on PATH (or where CreateProcess searches, anyway, such
as system32). So if the installer had such a feature, it should
be optional, and it should default to "off".
3. Most importantly: it is difficult to implement, and nobody has
contributed code to make it work.

Regards,
Martin

 

[Eric Pederson]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable. Every time, I've had to go through and add this by hand, to
have something resembling a usable Python installation. No such
problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or
Kubuntu. So why is the Windows install half-crippled by default? I just
rediscovered this today when trying to run one of the Turbogears
scripts, but this has puzzled me for years now.

+1

It is a pain for me because it is something I need to remember to do
maybe once a year or less.

It seems best practice with Windows is to throw away the machine every 2
years - so much crap gets automatically installed in places and ways not
solicited I'd think only cybermonks get away clean. That the Python
install is a good citizen in this regard is noble, but does it really
make a difference in regard to the overall Windows installation? And is
that difference worth the recurring pain of not having Python on the
path automatically?

There must be hundreds of programs on the PATH of the machine I type on,
its ugly. And lets not even talk about the Registry. Time to throw
away the machine. That's what I get for being a cheap slut for any
interesting program.


Windows will never be UNIX, invest in penicillin.

 

[Ben Sizer]

For several reasons:
1. Python can be used just fine without being on PATH. Python
scripts run fine both when double-clicked and when invoked in
the command line, and if you want to use an interactive
interpreter, you can find it readily on the Start menu.

Yet many scripts and applications require parameters, or to be executed
from a certain directory. For example, setup.py. Or the various
turbogears scripts. Or easy_install.

2. Many windows users (including myself) dislike setup routines that
manipulate PATH.

My opinion is that this is not as big a problem as some may feel that
it is. Unlike Unix systems, the PATH variable is rarely used. Most
applications are launched via the Start Menu, which uses absolute
paths, or via file associations, also done via absolute paths. The
chance of a naming collision only really arises when you start using
the command line, which most people don't do.

However, among those who will use the command line, are some people new
to Python, who will come across instructions like this:

<http://docs.python.org/inst/standard-install.html>

"As described in section 1.2, building and installing a module
distribution using the Distutils is usually one simple command:

python setup.py install

On Unix, you'd run this command from a shell prompt; on Windows, you
have to open a command prompt window (``DOS box'') and do it there; "

Pretty much none of the instructions in that part of the docs will work
without you altering your path beforehand. Python's cross-platform
nature means people rightly expect the same instructions to work on
Linux and Windows from a standard installation. Right now, they don't.

if Python is to be found in PATH, it
should rather be installed to a directory that is known to live
on PATH (or where CreateProcess searches, anyway, such
as system32). So if the installer had such a feature, it should
be optional, and it should default to "off".

It's a lot more anti-social to install to system32 than to modify the
PATH variable. How easy is it to temporarily undo an installation to a
system directory like that? What if you still want Python in your path
but with less precedence than some other user directory?

3. Most importantly: it is difficult to implement, and nobody has
contributed code to make it work.

There appears to be a freely-available binary at this address that may
suffice:
http://legroom.net/modules.php?op=modload&name=Open_Source&file=index&page=software&app=modpath

 

[vbgunz]

I've installed several different versions of Python across several
different versions of MS Windows, and not a single time was the Python
directory or the Scripts subdirectory added to the PATH environment
variable.

I don't understand what all the fuss is about. Add a single page to the
installer and on it, have 3 radio buttons. The choices could be "add to
path (recommended)", "add to path with version", "do not add to path
(not recommended)". On a brand new installation or if the user is
upgrading, "add to path (recommended)" should automatically be
selected. If the user is downgrading, "add to path with version" could
be the default selection? If a user truly does not want the Python
installation to touch the path, they'll know to select "do not add to
path (not recommended)" and it's the end of the story, everyone is
happy... It doesn't even have to be like this *but* why not help add
the install to the path?

I haven't used Windows in quite a while but I've done several
installations across some of the family boxes and some inside some
virtual machines and every time I tried launching python through a
console I temporarily got stunned with an error. I just forget and wish
the install could at least remind me. No problem, I know how to add the
path so no biggie at all. Some if not most python documentation assumes
Python is on the path... Anyhow, I don't get why it doesn't apply by
default in some way on Windows even if at the least it could be a
simple reminder or tip to do so.

 

[Tom Plunket]

I don't understand what all the fuss is about. Add a single page to the
installer and on it, have 3 radio buttons.

I don't understand what the fuss is about, and would not give that
recommendation based on my not understanding it!

I have never ever needed or wanted to launch the python interactive
interpreter from a command-line. IPython is what I want to use when I'm
going interactive, and running scripts from the command-line works just
fine with Windows's file associations.

Some if not most python documentation assumes Python is on the path...

Really? I must live in different places in the docs, but I can't recall
encountering any such documentation.

Anyhow, I don't get why it doesn't apply by default in some way on
Windows even if at the least it could be a simple reminder or tip to do
so.

Users who want it in their paths are certainly capable of putting it
there. I am in the camp that detests apps that automatically install
tons of crap everywhere without prompts. Certainly, though, the
suggestion that one pane in the installer offer to put it in the path
would leave the default as it is today ("don't edit PATH"), though,
right? Doesn't make a whole lot of sense to add a new option and
default it to something completely different from the old behavior, does
it?


-tom!

--

 

[robert]

My opinion is that this is not as big a problem as some may feel that
it is. Unlike Unix systems, the PATH variable is rarely used. Most

It is a big problem.

It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions.
This would create funny PATH variables - almost a "psychic behavior with history".

I'd vote heavily against manipulating the PATH.

Example: Just recently I had a lot of magical version problems with Borland stuff installers which by default and without question or noticeable checkboxes add naively (and multiple folders) to the PATH. And there were not just version mix-up problems - even things with same names of the C++ and the Pascal compilers and even stuff from old 16bit compilers wanted to deal with each other...

"Default Links" - generally speaking - are by far better than PATHs regarding application level stuff.

It's a lot more anti-social to install to system32 than to modify the
PATH variable. How easy is it to temporarily undo an installation to a
system directory like that? What if you still want Python in your path
but with less precedence than some other user directory?

Uninstallation would be same as for the pythonXX.dll.

A python(XX).exe next to the DLL would just be a natural consequence - the DLL already defined the policy. python.exe is nothing else than a DLL loader.

Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so...

If one really wants multi user separate installations that clean, it is all necessary to create oneself something like ....\<user>\bin <user>\system32. Yet not different from Linux: a ~\bin on the PATH would be custom with most *unix default layouts also.
Dealing with less and more precedence / PATH order is about the same issue : you have by far crossed the line from where you have to set yourself the PATH consciously.
And multiple Python installers automatically establishing the right precedence on the PATH !? - with re.sub()

Putting a pythonXX.exe next to pythonXX.dll into system32 should be a non-q and a kind of default comfort for multi-python users.
Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most "compatible" to *nix.


Robert

 

[Ben Sizer]

It is a big problem.

It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions.

So you think most Python users have more than one version of Python
installed? I disagree - but even if it is true, how come this isn't a
big problem on Unix? Can you name a single distribution that doesn't
install Python to the path?

This would create funny PATH variables - almost a "psychic behavior with history".

It is quite trivial to see if Python is already on the path, and act
differently based on that.

Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so...

So... that's another reason why there's rarely a problem in setting
that PATH variable.

Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most "compatible" to *nix.

No, it doesn't : the /scripts directory is also important for many
Python packages and that isn't addressed by shifting python.exe into
system32.

 

[Ben Sizer]

vbgunz wrote:

Really? I must live in different places in the docs, but I can't recall
encountering any such documentation.

I have posted a few examples above: "Installing Python Modules"
(http://python.org/doc/2.2.3/inst/inst.html) is a key example. 3rd
party packages often expect you to type "python setup.py install".
Setuptools/easyinstall will give you an 'easy_install' script, but then
notes that you have to manually fix up the PATH yourself.

Users who want it in their paths are certainly capable of putting it
there.

By that logic, users who want Python are probably capable of unzipping
the archive and putting it somewhere semi-suitable. So why provide an
installer?

If you're going to provide an installer, it should do the whole job,
and get Python in a state that is reasonably consistent across all
platforms, where practical. Adding to the PATH variable isn't
impractical.

I am in the camp that detests apps that automatically install
tons of crap everywhere without prompts.

Why use hyperbole here? Is 13 or 14 bytes optionally added to a single
environment variable "tons of crap"? And did anybody insist that the
installer would have no prompts?

Certainly, though, the
suggestion that one pane in the installer offer to put it in the path
would leave the default as it is today ("don't edit PATH"), though,
right? Doesn't make a whole lot of sense to add a new option and
default it to something completely different from the old behavior, does
it?

I have no problem with something being configurable, but I do have a
problem with Windows users being forced to jump through unnecessary
hoops that Unix and MacOS users don't have to endure. And I think the
default should be to edit the PATH and allow you to explicitly disallow
this: changing from the current behaviour is the right thing to do
because the current behaviour is wrong, in terms of cross-platform
compatibility and usability.

 

[Fuzzyman]

Ben Sizer wrote:
[snip..]

I have no problem with something being configurable, but I do have a
problem with Windows users being forced to jump through unnecessary
hoops that Unix and MacOS users don't have to endure. And I think the
default should be to edit the PATH and allow you to explicitly disallow
this: changing from the current behaviour is the right thing to do
because the current behaviour is wrong, in terms of cross-platform
compatibility and usability.

I strongly agree with these sentiments.

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml