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.

--
Ben Sizer

[vbgunz]

Ben Sizer wrote:

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.

--
Ben Sizer

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/show...kage_id=174569

vbgunz wrote:

Ben Sizer wrote:

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.

--
Ben Sizer

excellent question

[MC]

Hi!

+1

--
@-salutations

Michel Claveau

[Ross Ridge]

Ben Sizer wrote:

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]

Er*********@msn.com wrote:

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

[Ben Sizer]

Ross Ridge wrote:

Ben Sizer wrote:

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.

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.

--
Ben Sizer

[WaterWalk]

Ben Sizer wrote:

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]

WaterWalk wrote:

Ben Sizer wrote:

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.

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

[robert]

Ben Sizer wrote:

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

[benc_nospam]

Ross Ridge wrote:

Ben Sizer wrote:

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.

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?=]

Ben Sizer schrieb:

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]

Ben Sizer wrote:

>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]

Martin v. Löwis wrote:

Ben Sizer schrieb:

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.

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=mo...re&app=modpath

--
Ben Sizer

[vbgunz]

Ben Sizer wrote:

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]

vbgunz wrote:

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]

Ben Sizer wrote:

Martin v. Löwis wrote:

>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

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.

>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?

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]

robert wrote:

Ben Sizer wrote:

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.

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

[Ben Sizer]

Tom Plunket wrote:

vbgunz wrote:

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.

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.

--
Ben Sizer

[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

--
Ben Sizer

[Gabriel Genellina]

At Saturday 30/12/2006 21:55, Ben Sizer wrote:

>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.

Notice that there is NO need to alter the system path. You just have
to tell Windows where python.exe resides; there is a per-application
path located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\App Paths.
In order to launch Python just writing "python" at the command
prompt, the installer should -instead of playing with the system
path- create a new key below App Paths, named "python.exe", and set
its default value to the full path of the installed python executable.
See
http://msdn.microsoft.com/library/en...ived_types.asp
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Chris Lambacher]

On Sat, Dec 30, 2006 at 04:55:09PM -0800, Ben Sizer wrote:

Martin v. L?wis wrote:

Ben Sizer schrieb:

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.

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.

Martin's point was that if you need to pass arguments, you can call the script
from the command line like so:
setup.py install

The python part of the 'python setup.py install' idiom needs to be omitted on
Windows, but that does not mean that the solution is to automatically add it
to PATH.

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>
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.

The documentation is misleading... time for a but report:
http://sourceforge.net/tracker/index...70&atid=105470

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?

I agree an optional add to PATH, should just add to the path rather than
install python.exe into a location on the path.

>

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=mo...re&app=modpath

Unfortunately the Python installer is not an InnoSetup installer. If you
converted this code to Python you might get farther since the MSI could call
an add2path script with the newly installed Python executable. I am sure
submitting a patch for the installer option would also help your cause.

-Chris

[Ben Sizer]

Gabriel Genellina wrote:

At Saturday 30/12/2006 21:55, Ben Sizer wrote:

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.

Notice that there is NO need to alter the system path. You just have
to tell Windows where python.exe resides; there is a per-application
path located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\App Paths.
In order to launch Python just writing "python" at the command
prompt, the installer should -instead of playing with the system
path- create a new key below App Paths, named "python.exe", and set
its default value to the full path of the installed python executable.
See
http://msdn.microsoft.com/library/en...ived_types.asp

>From what I can tell, that is solely for file associations. If so, it

will work if you type "setup.py install" but not if you type "python
setup.py install". For instance, I have an entry for Firefox in that
part of the registry, but if you try executing "firefox" at the command
line, it fails.

It also doesn't solve the issue of utility scripts being added to
Python's scripts directory.

--
Ben Sizer

[Thomas Heller]

Ben Sizer schrieb:

Gabriel Genellina wrote:

>Notice that there is NO need to alter the system path. You just have
to tell Windows where python.exe resides; there is a per-application
path located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Cur rentVersion\App Paths.
In order to launch Python just writing "python" at the command
prompt, the installer should -instead of playing with the system
path- create a new key below App Paths, named "python.exe", and set
its default value to the full path of the installed python executable.
See
http://msdn.microsoft.com/library/en...ived_types.asp

>>From what I can tell, that is solely for file associations. If so, it

will work if you type "setup.py install" but not if you type "python
setup.py install". For instance, I have an entry for Firefox in that
part of the registry, but if you try executing "firefox" at the command
line, it fails.

Not really. It's for ShellExecute, which is used for the 'run' entry in the
start menu, or when you type 'start firefox' from the command line.

Thomas

[Ben Sizer]

Chris Lambacher wrote:

On Sat, Dec 30, 2006 at 04:55:09PM -0800, Ben Sizer wrote:

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.

Martin's point was that if you need to pass arguments, you can call the script
from the command line like so:
setup.py install

The python part of the 'python setup.py install' idiom needs to be omitted on
Windows, but that does not mean that the solution is to automatically add it
to PATH.

Firstly, that solution only works for actual Python scripts; it doesn't
solve the utility scripts that are often installed to the /scripts
directory. It's a shame that many responses on this thread don't
address that half of the issue. Am I the only person who installs
packages that add scripts (not all of which are Python ones)?

Secondly, it's still a significant difference from the Unix-based
installs. You're right, the solution doesn't automatically have to be
adding it to the PATH - but I'm yet to see a good argument for choosing
not to, apart from "I don't like it when apps do that".

The documentation is misleading... time for a but report:
http://sourceforge.net/tracker/index...70&atid=105470

Fixing the docs is better than nothing, but I believe fixing the
install to encourage uniform usage across all platforms is preferable,
and that in this regard the documentation shows how it 'should' work.

There appears to be a freely-available binary at this address that may
suffice:
http://legroom.net/modules.php?op=mo...re&app=modpath

Unfortunately the Python installer is not an InnoSetup installer.

The page I linked to is a bit misleading but there is an executable on
that page. All you then have to do is invoke it with the relevant
parameter.

--
Ben Sizer

[Gabriel Genellina]

At Tuesday 2/1/2007 13:58, Ben Sizer wrote:

Notice that there is NO need to alter the system path. You just have
to tell Windows where python.exe resides; there is a per-application
path located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\App Paths.

From what I can tell, that is solely for file associations. If so, it

will work if you type "setup.py install" but not if you type "python
setup.py install". For instance, I have an entry for Firefox in that
part of the registry, but if you try executing "firefox" at the command
line, it fails.

Typing "start firefox" at the command line should work.
It appears that cmd.exe does *not* use ShellExecute to find the
executable, so this approach doesn't work as expected :(
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Chris Lambacher]

On Tue, Jan 02, 2007 at 09:08:41AM -0800, Ben Sizer wrote:

Chris Lambacher wrote:

On Sat, Dec 30, 2006 at 04:55:09PM -0800, Ben Sizer wrote:

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.

Martin's point was that if you need to pass arguments, you can call the script
from the command line like so:
setup.py install

The python part of the 'python setup.py install' idiom needs to be omitted on
Windows, but that does not mean that the solution is to automatically add it
to PATH.

Firstly, that solution only works for actual Python scripts; it doesn't
solve the utility scripts that are often installed to the /scripts
directory. It's a shame that many responses on this thread don't
address that half of the issue. Am I the only person who installs
packages that add scripts (not all of which are Python ones)?

Nope, but just adding the scripts directory to the PATH does not solve the
problem. You also need to either create an executable launcher (.bat or
..exe) for the script or mess with environment variables to tell Windows to
treat .py files a executable. This issue is solved in Unix by toggling the
executable bit on the file in the file system.

Easy Install helps the situation by making an executable of the same name as
the script which calls the script. There has been discussion on the distutils
mailing list about how to put this in the user's path. No good solution has
been proposed. If Easy Install were made the default distribution method, or
distutils spawned the ability to handle scripts in a similar manner, I would
be in favour of optionally adding scripts to PATH. Whether that option is on
by default or not could be debated at that time.

>
Secondly, it's still a significant difference from the Unix-based
installs.

Its not really. Unix installs default to being installed to the prefix /usr,
which just happens to put the executable in your path. It does not modify the
user's path in any way. If you install to some location that is not in your
path it is your responsibility to add that location to your path or provide an
explicit path. Some of the problems caused by this are mitigated by the way
Unix identifies executables.

You're right, the solution doesn't automatically have to be
adding it to the PATH - but I'm yet to see a good argument for choosing
not to, apart from "I don't like it when apps do that".

The documentation is misleading... time for a but report:
http://sourceforge.net/tracker/index...70&atid=105470

Fixing the docs is better than nothing, but I believe fixing the
install to encourage uniform usage across all platforms is preferable,
and that in this regard the documentation shows how it 'should' work.

There appears to be a freely-available binary at this address that may
suffice:
http://legroom.net/modules.php?op=mo...re&app=modpath

Unfortunately the Python installer is not an InnoSetup installer.

The page I linked to is a bit misleading but there is an executable on
that page. All you then have to do is invoke it with the relevant
parameter.

Sorry, I saw the Inno version and the AutoIt and did not see the compiled
executable version. I still think it will be more likely to be accepted if
the code was translated into Python, since shipping another executable will
not be required.

>
--
Ben Sizer

--
http://mail.python.org/mailman/listinfo/python-list

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

Ben Sizer schrieb:

Firstly, that solution only works for actual Python scripts; it doesn't
solve the utility scripts that are often installed to the /scripts
directory.

Those packages should install .bat files into /scripts on Windows.

It's a shame that many responses on this thread don't
address that half of the issue. Am I the only person who installs
packages that add scripts (not all of which are Python ones)?

Perhaps not. However, people apparently disagree what the "full issue"
is. If you have non-Python scripts (eg. VBScript) in /scripts, how will
having python.exe on PATH help at all?

>Unfortunately the Python installer is not an InnoSetup installer.

The page I linked to is a bit misleading but there is an executable on
that page. All you then have to do is invoke it with the relevant
parameter.

Please submit a patch that does so, then. Make sure you add user
interface to make it an option.

These things are *not* easy, and claiming that they are is
misleading.

Regards,
Martin

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

vbgunz schrieb:

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)".

Please submit a patch to sf.net/projects/python that does so.

Regards,
Martin

[Ben Sizer]

Chris Lambacher wrote:

On Tue, Jan 02, 2007 at 09:08:41AM -0800, Ben Sizer wrote:

Chris Lambacher wrote:

The python part of the 'python setup.py install' idiom needs to be omitted on
Windows, but that does not mean that the solution is to automatically add it
to PATH.

Firstly, that solution only works for actual Python scripts; it doesn't
solve the utility scripts that are often installed to the /scripts
directory. It's a shame that many responses on this thread don't
address that half of the issue. Am I the only person who installs
packages that add scripts (not all of which are Python ones)?

Nope, but just adding the scripts directory to the PATH does not solve the
problem. You also need to either create an executable launcher (.bat or
.exe) for the script or mess with environment variables to tell Windows to
treat .py files a executable. This issue is solved in Unix by toggling the
executable bit on the file in the file system.

Many of the scripts that are installed come as batch files or other
executables. They just assume the directory is in your PATH already,
which they aren't, until you set it that way.

Secondly, it's still a significant difference from the Unix-based
installs.

Its not really. Unix installs default to being installed to the prefix /usr,
which just happens to put the executable in your path. It does not modify the
user's path in any way.

I was talking more in terms of the end-user experience. I don't know of
any binary package on the distros I've used (Mandriva/Mandrake, Fedora
Core, and Kubuntu) that install Python without it going into your path,
nor of any that allow you to avoid that while using their standard
package managers. It may be incidental in some meaning of the term, but
it's expected and apparently intended.

--
Ben Sizer

[Ben Sizer]

Martin v. Löwis wrote:

Ben Sizer schrieb:

Firstly, that solution only works for actual Python scripts; it doesn't
solve the utility scripts that are often installed to the /scripts
directory.

Those packages should install .bat files into /scripts on Windows.

Which still need their location to be be fully qualified, due to
/scripts not being in the path. This is not my experience with Linux
installations of the same packages.

Please submit a patch that does so, then. Make sure you add user
interface to make it an option.

These things are *not* easy, and claiming that they are is
misleading.

I will look into it.

--
Ben Sizer

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

Ben Sizer schrieb:

>Those packages should install .bat files into /scripts on Windows.

Which still need their location to be be fully qualified, due to
/scripts not being in the path. This is not my experience with Linux
installations of the same packages.

Ah, so you not only want the directory that contains Python added to
the path, but also /scripts. That's again a new requirement, and I
think it is the first time that somebody requests it.

Regards,
Martin

[vbgunz]

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)".

Please submit a patch to sf.net/projects/python that does so.

If I could I would. My only point jumping in here is this; adding
python to the path has got to be more beneficially productive for
everyone than not adding it at all. I don't even use Windows enough to
complain about it and I thought I'll voice my agreement on it.

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

vbgunz schrieb:

>>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)".

Please submit a patch to sf.net/projects/python that does so.

If I could I would. My only point jumping in here is this; adding
python to the path has got to be more beneficially productive for
everyone than not adding it at all. I don't even use Windows enough to
complain about it and I thought I'll voice my agreement on it.

Ok. So I can answer your (implied) question: much of the fuss is about
lack of contributions.

Regards,
Martin

[robert]

Ben Sizer wrote:

robert wrote:

>Ben Sizer wrote:

>>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.

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?

As said - yes they install the 'pythonx.y' binary or just 'python' default link _into_ the path (/usr/local/bin or /usr/bin). Yet they don't manipulate any 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.

When you run an installer you first lookup the PATH and according to your look you hit or not-hit the (future) checkbox in the installer and/or edit the PATH later to only have one python main folder in it?
You could as well edit the PATH at all yourself as one can do it now.

>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.

mix-up with PATH is already there for a single user. I named a most negative example (Borland) and would not use such checkbox in a Python installer which would allow to manipulate the PATH in hardly predictable manner.

>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.

Now you want also the scripts directory on the PATH? I don't even see this stuff on linux py's nor PATH's.

But as somebody said, we could have 3 or 4 options in the installer. Just who will supply MvL with the patch, which is truely not trivial.

Most cheap and consistent is:

Create pythonXY.exe always next to the pythonXY.dll auto. This is the same as having usr/local/pythonX.Y on linux. (Personally I anyway like to call exactly the python i want.)

Then a future option 2 - as I'd favor it next to the current "do nothing" - would probably also most simple for system installations:

If checkbox "copy python.exe into System Folder" then copy/overwrite python.exe into System Folder. There is not much magic and not much precedence worries about it and every developer knows clearly what happens. If multi-pythons, one knows that this would create the new default "python" on the command line unless one has custom things in front on the PATH.

Then there could be advanced options 3, 4, .. for PATHs: With questions: Replacing in User- and/or System-PATH?, prepending-to-User/System-PATH?, appending-to-User/System-PATH, the same for the Script-folders and all fancy things and side-effects etc. - if consistent patches will ever be supplied ...
I'd not use these options a lot anyway because I like Python to answer my questions - not reverse :-)
Robert