Why does Python never add itself to the Windows path?

[Gabriel Genellina]

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\CurrentVersion\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/e...nding/fileassociations/fa_perceived_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]

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.

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.php?func=detail&aid=1626300&group_id=5470&atid=105470

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.

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

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]

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\CurrentVersion\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/e...nding/fileassociations/fa_perceived_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.

 

[Thomas Heller]

Gabriel Genellina wrote:


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]

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.php?func=detail&aid=1626300&group_id=5470&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.

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.

 

[Gabriel Genellina]

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]

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


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.



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.

 

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

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?

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

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]

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.

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]

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.

 

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

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

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

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]

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.

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.

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.

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