Why does Python never add itself to the Windows path?

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