Windows installer should add Python and Scripts directories to the PATH environment variable

[jasonspiro]

BPO	3561
Nosy	@loewis, @ncoghlan, @pitrou, @giampaolo, @tiran, @merwok, @briancurtin, @JimJJewett
Files	issue3561.diff issue3561_v2.diff issue3561_v3.diff news_dialog.diff path_option.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/briancurtin'
closed_at = <Date 2012-11-03.18:04:23.646>
created_at = <Date 2008-08-15.17:16:22.818>
labels = ['type-feature', 'expert-installation', 'OS-windows']
title = 'Windows installer should add Python and Scripts directories to the PATH environment variable'
updated_at = <Date 2014-05-10.17:53:10.135>
user = 'https://bugs.python.org/jasonspiro'

bugs.python.org fields:

activity = <Date 2014-05-10.17:53:10.135>
actor = 'python-dev'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2012-11-03.18:04:23.646>
closer = 'loewis'
components = ['Installation', 'Windows']
creation = <Date 2008-08-15.17:16:22.818>
creator = 'jasonspiro'
dependencies = []
files = ['25151', '25255', '25266', '25700', '26101']
hgrepos = []
issue_num = 3561
keywords = ['patch', 'needs review']
message_count = 50.0
messages = ['71172', '71174', '71185', '71190', '134326', '134328', '134333', '152706', '152707', '152709', '152711', '153761', '157124', '157735', '157892', '157893', '157895', '157897', '157909', '157911', '157921', '158588', '158672', '158680', '159259', '159280', '159283', '159288', '159289', '159295', '159298', '159305', '161528', '161530', '161531', '161532', '161533', '161539', '161581', '161585', '163529', '163538', '164630', '164635', '164660', '164661', '164662', '174645', '174657', '218227']
nosy_count = 16.0
nosy_names = ['loewis', 'ncoghlan', 'pitrou', 'giampaolo.rodola', 'christian.heimes', 'eric.araujo', 'jasonspiro', 'lambacck', 'brian.curtin', 'jonathan.hartley', 'pekka.klarck', 'python-dev', 'AaronR', 'jdigital', 'Jim.Jewett', 'helder-magalhaes']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3561'
versions = ['Python 3.3']

[jasonspiro]

The Python Windows installer[1] should automatically add the Python and
Scripts directories to the PATH environment variable. (If you like,
you can also provide a checkbox in the installer GUI that users can
uncheck if they don't want this behavior.)

This issue was discussed at http://nabble.com/Why-does-Python-never-add-
itself-to-the-Windows-path--td8044465.html and the majority consensus
was that this is a good idea, but nobody has volunteered to implement
it.

^ [1]. The installer is generated by the code at
http://svn.python.org/view/python/trunk/Tools/msi/

[loewis]

I still don't think such a change should be made, hence I reject this
report as "won't fix". Discussion shouldn't start again on this matter
until there is an actual patch to review.

[jasonspiro]

Martin, at the time I read the python-list thread, I didn't pay any
attention to the posts' authors. Only now did I realize you were one
of the posters. Oops.

I already know the basic ideas about creating MSIs with Wise from a
past job. So now I researched and thought about this particular
problem for several hours. I've learned that Windows Installer is able
to add ...\python and ...\python\scripts to the PATH during
installation. It cannot[1] remove them at uninstallation. [ WiX, and
its superior competitor MAKEMSI, each provide slightly higher-level
abstractions[2][3] on top of what Windows Installer provides[4] to make
this slightly easier, but not by that much. But I will assume you
don't plan to spend days or weeks of your spare time on migrating away
from msilib. :-) ]

Here are the rough notes I've made up so far on how to do this:

• make a new method add_environment. In it:
  • call start_component to create components "modify_path_per_user"
    and "modify_path_per_machine"
  • call add_data to create an Environment table. It should have
    two rows[5]:
    • Name:"=PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]"
      Component:"modify_path_per_user"
    • Name:"=*PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]"
      Component:"modify_path_per_machine"

Another difficult part is the UI. Then there's the issue of switching
which of the two components are installed based on whether it's per-
user or per-machine and also based on whether the user specifies via
the UI that they want their PATH changed. I have to think more about
that, and I'm already tired of researching.

Remember that Windows Installer cannot undo its PATH changes at
uninstall time. So, before I consider proceeding further, let me
verify a few things with you.

1. [TARGETDIR] will stay on the path. I think that is fine, since the
   python.exe will be gone, so will never be executed. Do you agree?

2. [TARGETDIR]\scripts will also stay on the path. And it may still
   contain scripts installed by the user or by third-party installers like
   the SCons installer. I don't know enough about how Python works to
   know if that's a problem. Is it a problem?

P.S. Would you prefer to discuss this by something more synchronous
like telephone (I will pay the tolls) or instant messaging?

P.P.S. Now that I have realized how complicated Python installation
actually is, and how hard it is to design the tables of and write
raw .MSI files, I have a new appreciation for the work you've done on
making a Python MSI installer. Thank you very much for having done
so. Also, now that I have started researching how much work is
necessary to get this done, I realize why you don't want to code it
yourself. :-)

I don't know if I will end up actually managing to come up with a patch.

^ [1]. I have inferred this fact based on
http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down
to the "Setting the PATH" section
^ [2]. http://blogs.technet.com/alexshev/archive/2008/03/28/from-msi-
to-wix-part-13-installable-items-environment-variable.aspx
^ [3]. http://makemsi-manual.dennisbareis.com/path.htm
^ [4]. http://msdn.microsoft.com/en-us/library/aa368369(printer).aspx
^ [5]. Search inside the page http://msdn.microsoft.com/en-
us/library/aa368369(printer).aspx for "If the package can be installed
per-user or per-machine" to see why you need two rows.

[loewis]

1. [TARGETDIR] will stay on the path. I think that is fine, since the
   python.exe will be gone, so will never be executed. Do you agree?

Completely disagree. Adding something to PATH is nearly unacceptable
clutter even during installation, and completely unacceptable (to me)
after uninstallation. If you install Python several times, will the path
get longer and longer?

In principal, uninstallation should completely undo installation. There
should be only plausible exceptions, e.g. when the user still has files
in a directory, deleting the directory is unacceptable as it would also
delete the files. The big problem where the Python installer (and MSI
in general) fails is uninstallation of file associations, which doesn't
restore the file assocations to what they were (of course, that software
might be gone)

2. [TARGETDIR]\scripts will also stay on the path. And it may still
   contain scripts installed by the user or by third-party installers like
   the SCons installer. I don't know enough about how Python works to
   know if that's a problem. Is it a problem?

To me, any change to PATH is a problem... (I really think that software
installation should never ever touch it - this aspect of the operating
system completely belongs to the user resp. the system administrator)

P.S. Would you prefer to discuss this by something more synchronous
like telephone (I will pay the tolls) or instant messaging?

I don't think this can be done for 2.6, so there is no need for
synchrony - there is plenty of time to come up with a solution
for 2.7/3.1. In any case, I'll be away for the next three weeks.

It cannot[1] remove them at uninstallation.
^ [1]. I have inferred this fact based on
http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down
to the "Setting the PATH" section

I think this is incorrect. You cannot uninstall the path through
unsetting the PATH variable, sure. So perhaps using the Environment
table is the wrong approach in the first place. You can do nearly
anything in a custom action, so it should be possible to remove the
path entry on uninstallation by means of a custom action.

If such a solution was designed, there would still be many questions,
such as:

• what is the actual problem being solved? Is it real? Could there
  be other solutions to that problem (such as installing things into
  system32, or somewhere else that is on the PATH already)?
• if the path is modified, should the Python directory be added to
  the beginning or the end?
• IMO, this feature needs to be customizable, and IMO, it must be
  turned off by default. So how should such customization be offered?
  These questions can partially be discussed in the tracker item proposing
  the patch. The very end-user related aspects of it need to be discussed
  on python-dev (perhaps taking a poll whether this is desirable, whether
  it should be optional, and if so, what the default should be)

[ncoghlan]

Reopening this issue since bpo-9228 was closed as a duplicate of this one. Given the significant level of user demand for this behaviour, it should NOT be closed again until a PEP has been written and either accepted or rejected. If such a PEP is not written and championed through to a final decision, then this issue should remain open indefinitely.

Such a PEP should canvas the option of installing development shell launch scripts into the Start menu and updating the documentation accordingly as an alternative to messing with the system-wide PATH setting.

An install-time option to allow power users to disable the PATH manipulation should also be considered. The interests of novice Python users and experienced Windows system administrators are not in alignment on this topic, and the current installer behaviour favours the latter at the expense of the former.

[ncoghlan]

Now, another factor to consider is that Windows 7 makes manipulating the system PATH even more difficult to do correctly (e.g. see http://www.symantec.com/connect/forums/wise-7-win-7-problems-updating-environment-variable-current-user).

I believe ActiveState handle this by making the PATH modification optional and having it off by default (I found docs for ActivePerl stating this explicitly, but no equivalent for ActivePython).

Regardless, for a product intended for heavy command line use, we should definitely do better in either providing a way for users to request that the installer modify PATH directly, or else a way to easily launch a command shell with PATH updated appropriately.

[srid]

I believe ActiveState handle this by making the PATH modification
optional and having it off by default (I found docs for ActivePerl
stating this explicitly, but no equivalent for ActivePython).

ActivePython 2.x has it on by default.

[helder-magalhaes]

See tightly related ActivePython issue [1] regarding the way directories are added to the PATH environment variable.

Also, here's qooxdoo (a well-known JavaScript framework) giving out instructions [2] on how to use the official python distribution due to the missing path and file association treatment (and also redirecting the preference to ActivePython for that).

(Setting to all versions as I believe this isn't addressed in any previous or current release.)

[1] http://bugs.activestate.com/show_bug.cgi?id=92615
[2] http://manual.qooxdoo.org/current/pages/getting_started/troubleshooting.html#windows

[briancurtin]

FWIW I have an installer built which optionally adds to the path. It's not complete - still needs some GUI work to hook it all up, but I'll be proposing it shortly.

[loewis]

Helder: please don't change tracker settings unless you know what they are for. Python 2.6 and 3.1 can't possibly see any change here since they are in security fix mode, and can't see any fixes affecting this issue. Likewise, 2.7 and 3.2 will only see bug fixes. As the lack of supporting changes to Path isn't a bug (but possibly a missing feature), these versions can't see the bug, either. Putting 3.4 and 3.3 into an issue is just nonsense at this point: if the issue gets resolved for 3.3 before 3.4 is released, it will never be an issue for 3.4.