classification
Title: Windows installer should add Python and Scripts directories to the PATH environment variable
Type: enhancement Stage: resolved
Components: Installation, Windows Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brian.curtin Nosy List: AaronR, Jim.Jewett, brian.curtin, christian.heimes, eric.araujo, giampaolo.rodola, helder-magalhaes, jasonspiro, jdigital, jonathan.hartley, lambacck, loewis, ncoghlan, pekka.klarck, pitrou, python-dev
Priority: normal Keywords: needs review, patch

Created on 2008-08-15 17:16 by jasonspiro, last changed 2012-11-03 18:04 by loewis. This issue is now closed.

Files
File name Uploaded Description Edit
issue3561.diff brian.curtin, 2012-04-07 15:45
issue3561_v2.diff brian.curtin, 2012-04-18 04:48 review
issue3561_v3.diff brian.curtin, 2012-04-18 22:43 review
news_dialog.diff brian.curtin, 2012-05-25 00:11 review
path_option.diff brian.curtin, 2012-06-23 03:55 review
Messages (49)
msg71172 - (view) Author: Jason Spiro (jasonspiro) Date: 2008-08-15 17:16
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/
msg71174 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-08-15 18:03
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.
msg71185 - (view) Author: Jason Spiro (jasonspiro) Date: 2008-08-15 21:22
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.
msg71190 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-08-15 23:01
> 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)
msg134326 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-04-24 09:43
Reopening this issue since #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.
msg134328 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-04-24 10:07
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.
msg134333 - (view) Author: Sridhar Ratnakumar (srid) Date: 2011-04-24 16:59
> 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.
msg152706 - (view) Author: Helder Magalhães (helder-magalhaes) Date: 2012-02-05 20:40
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
msg152707 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-02-05 20:43
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.
msg152709 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-02-05 21:11
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.
msg152711 - (view) Author: Helder Magalhães (helder-magalhaes) Date: 2012-02-05 22:02
@Brian: glad to know about it. It will surely help, as many Windows users aren't much comfortable with the console already, and even less comfortable for tweaking the system at this level (apart from permission issues, etc.). ;-)

@Martin: you're right, sorry. I'd swear I several versions selected and only a couple missing, but probably I was tricked by a related/duplicate issue. Better read the manual next time... :-)
msg153761 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-02-20 02:34
Attached is an in-progress patch.

I still need to figure out how to hook up the GUI to condition the path manipulation. A few locations have said to do conditional environment modification via the Component table, but I haven't been able to get some placeholder in there based on whether or not PREPEND is true/false from the GUI.

Right now if you build an installer with this it will always modify the path even if you haven't chosen the option to do so.

http://briancurtin.com/python-dev/python-3.3.15390.msi is an example installer. Note that it's not a signed installer, it's unofficial, and I don't support it whatsoever. It's merely provided as a sample of what the GUI looks like, and you can install it, see what happens, then uninstall and see that the path modification is properly undone.
msg157124 - (view) Author: Jeff Dean (jdigital) Date: 2012-03-30 03:03
I just saw Brian Curtin's Pycon 2012 presentation.  If a goal is to make it easy for new users to run python, consider installing a desktop shortcut.  This would make it very easy for new users (easier than starting up a shell).

This is independent of the Path changes discussed here.  Those should be made (or not made) on their own merit, since most users will eventually need the Path to be properly adjusted.
msg157735 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-07 15:45
Attached is issue3561.diff which adds a path option, off by default, as a feature to be installed. I've tested installation and un-installation with the feature both installed and not installed and it seems to work fine for me.

http://briancurtin.com/python-dev/python-3.3.15437.msi is an installer built with this patch. http://briancurtin.com/python-dev/CustomizePage.png is simply a screenshot of the page where you choose to enable this feature.
msg157892 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2012-04-09 20:26
@Brian -- to clarify, 

(1)  Does issue3561.diff completely supersede prependpath_in-progress.diff?  (And should that be the one currently subject to review?)

(2)  What happens with multiple installations?  Do users have to manually unset the path to avoid surprises?  Does this become obsolete if the py.exe shim delegating to the appropriate py* is included with 3.3?  Does installing 3.3.2 in over top of 3.3.1 add the directory to the path twice?
msg157893 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-09 20:36
UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software?
msg157895 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-09 20:45
I unlinked the old diff. issue3561.diff is the one that matters.

As for what happens with multiple installations, it's no different than how you'd already be managing it or anything else like it. If you install 2.7 with the path option enabled and then you install 3.2 with the path option enabled, 3.2 goes in front of 2.7. The installations don't touch each other. If we want to get smart and detect other installations on the Path, I believe this gets a lot more complicated.

It does not become obsolete with the launcher. The launcher solves a wider problem in a different way. You could just switch to the launcher if you wanted to, but because we (probably will) have that feature doesn't mean the bare python.exe can't grow this functionality. People have been asking for it for years. It's the first step of every tutorial on the internet. It takes up a special page on the information for a sprint I just saw.

As for the question of 3.3.2 over 3.3.1: I'm not sure yet. I'll build a few installers with different versions and run some upgrades to see what happens. We're using MSI's builtin ability to manage everything here, so I would imagine it knows what to do, but I'll confirm.
msg157897 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-09 20:47
> UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software?

I originally did it as a separate check box UI-wise but couldn't hook that into be an actual "Feature" in MSI terms. The way it's currently done allows it to be added to certain tables, allowing us to conditionally modify the "Environment" table which contains the optional path addition.

I am by no means an MSI expert. This is just the way Martin and I talked about it at PyCon and the way I've seen it done around the web. If there's a way to tie a checkbox to the Feature table, I would like that.
msg157909 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-09 21:52
> UI-wise, I'm not sure why it looks like an installable component  
> rather than a separate checkbox. Is it a limitation of the  
> installation software?

You are misinterpreting the UI. The list is not of "installable components",
but of "features". Adjusting the path is a feature just as registering the
.py extension. That feature can be installed and uninstalled.
msg157911 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-09 22:05
IANANSOE (I am not a native speaker of English), but it seems to me that "Prepend path" is a bit terse, in particular since "Path" is being prepended *to*. How about "Add python.exe to the search path"? That it is added to the beginning could be elaborated (i.e. prepended) in the feature description.
msg157921 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-09 22:59
Agreed. I will work up a more friendly text to go along with the feature.
msg158588 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-18 04:48
Here's a patch with better wording, and here's a screenshot of what the feature selection looks like with that text: http://i.imgur.com/k7e12.png
msg158672 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-18 22:08
A minor thing: The capitalization of the feature names is inconsistent.
msg158680 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-18 22:43
The attached patch changes the feature text to "Add python.exe to Path". I'm not sure the word "search" adds much there anyway.

An additional change here that I think would be beneficial is a better description text, immediately covering the benefit of this feature. I had to do some minor resizing of the relevant text boxes, but the description is now...

Prepend C:\Python33 to the system Path variable. This allows you to type 'python' into a command prompt without needing the full path.
msg159259 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-25 06:58
Brian: The patch is fine, please apply.
msg159280 - (view) Author: Roundup Robot (python-dev) Date: 2012-04-25 13:13
New changeset 4e9f1017355f by Brian Curtin in branch 'default':
Fix #3561. Add an option to place the Python installation into the Windows Path environment variable.
http://hg.python.org/cpython/rev/4e9f1017355f
msg159283 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-25 13:26
Now that the feature is in, I'm going to track the few places we need to document it in #14668.
msg159288 - (view) Author: Chris Lambacher (lambacck) * Date: 2012-04-25 14:35
I am really happy to see this as an option in the Windows installer. This has a potential to really reduce the support burden on training new Windows users to use Python and will really help normalize the experience for new users between Windows and POSIX platforms.

Unfortunately, from what I can tell, this is OFF by default. I think that is a mistake. The default for something like this is really important because without new users being explicitly told to set it, new users will not. Most new Python users are just going to take the default values and still be confused by not being able to open the console and run python as in the instructions for various new user tutorials (i.e. web frameworks, scientific computing, etc).

I understand the issue with installing multiple Python versions, but generally speaking people are going to want to install the latest version and have that be on their path. My sense is that there is a relative minority of Windows users that care about multiple versions of Python would not want their path to be updated. Unfortunately the ones who don't want their path updated are the ones that have driven the installer development at this point and will be most vocal in the Python community. 

I suggest a compromise which makes adding to the PATH default to ON if another Python version is not installed and/or on the PATH and default to OFF otherwise.

It looks like you can use a condition table plus the feature table to check for Python in the path buy I am not exactly an expert with MSI. My quick check found:
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx which says you can do a search for an installed component and then set a property. This should then allow setting of the default state of the feature based on a condition.

I really recommend that while we still have a chance to make a change that we think about the goal of this feature and whether making it disabled by default achieves those goals.
msg159289 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-25 14:50
lambacck: I'm -1, but I'm willing to yield to anybody who wants to be "in charge" of this feature (i.e. Brian, or the release manager). I'm not willing yield to "mere" user requests, as regular users won't have to deal with negative consequences that enabling this by default may have.

I'm quite opposed to your proposed conditional approach; I think this will be highly confusing to users.
msg159295 - (view) Author: Chris Lambacher (lambacck) * Date: 2012-04-25 15:11
The reason for the conditional approach was to attempt to account for the "negative consequences" of adding enabling this by default. i.e. if you are already a Python developer and install a new version, it will be status quo, but if you are a new Python developer then you will be able to run instructions for packages that work perfectly fine on Windows but are maintained and documented by POSIX users and don't understand that the steps to make things work on Windows are different.

I don't care one way or the other about the compromise position but I strongly believe that if someone is installing Python on Windows for the first time they should get a good experience without having to know of the existence of docs like: http://docs.python-guide.org/en/latest/starting/install/win/

This tweet https://twitter.com/#!/zedshaw/status/194853198006198272 is characteristic of the sentiment that non-Windows users have about training Windows users to develop with Python. At the PyCon web summit several people who have been doing training lately have said that their solution is to get windows users to run a Linux Virtual Machine because the Windows Python experience is so bad for new Windows developers. This is one relatively easy place where we can make that experience better.
msg159298 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-25 15:20
> Unfortunately, from what I can tell, this is OFF by default. I think
> that is a mistake. The default for something like this is really
> important because without new users being explicitly told to set it,
> new users will not. Most new Python users are just going to take the
> default values and still be confused by not being able to open the
> console and run python as in the instructions for various new user
> tutorials (i.e. web frameworks, scientific computing, etc).

To put things in perspective, the default under POSIX ("make install")
is to make the installed version the default (by copying it
into /usr/bin/python3). To change that behaviour, you have to use "make
altinstall" explicitly.
msg159305 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-25 15:42
[Jeff Dean]
> If a goal is to make it easy for new users to run python, consider installing a desktop shortcut.
> This would make it very easy for new users (easier than starting up a shell).
> This is independent of the Path changes discussed here.

Hi Jeff; thanks for the suggestion.  Could you open another bug report for it?  It’s much more manageable to have one request per report.  Thanks in advance.
msg161528 - (view) Author: Pekka Klärck (pekka.klarck) Date: 2012-05-24 21:00
I found about this enhancement via Python Insider blog post [1] that also asked adding comments to this issue. Here are mine:

1) Great to see that this is finally done!

2) Is only Python installation directory added into PATH? Why not also Scripts directory under it as originally requested in this issue? As a developer of a Python based test automation tool, just adding Python into PATH doesn't help us because our tool's launcher scripts still aren't found unless PATH is manually edited.

3) I would also prefer this to be on by default.

[1] http://blog.python.org/2012/05/recent-windows-changes-in-python-33.html
msg161530 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-05-24 21:28
2. Yes, only the installation directory, because that's the only directory we create. Scripts is created by distutils/packaging, but perhaps we could add it since it is widely used. Anyone have an opinion?

3. Do you have a reason? Many tools that offer path manipulation do not do so by default because it changes how the system operates. If we put this on by default, it will change how a lot of scripts are executed without people expecting it. It's easy to click through an installer like Python's because it's not flashy and there aren't a lot of options as it is. If we just let people click through, things are going to break a lot more than if we make people ask for it.

I could see it becoming a default in a future release once it has been in the wild for a while, but I think we're going to run into a lot of problems if we just flip it right away.
msg161531 - (view) Author: Pekka Klärck (pekka.klarck) Date: 2012-05-24 21:36
Being on by default would just be easier. If it's off, we still need to separately instruct users to turn it on. That's obviously a lot easier than instruction them to change environment variables, so I don't feel too strongly about it.

Not adding Scripts into PATH, on the other hand, would make this enhancement pretty useless for us. If it's considered confusing that the installer adds a directory it doesn't create into PATH, perhaps the installer could be changed to also create that directory.
msg161532 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-05-24 21:37
For 3, installing the PEP 397 launcher will be the long term "on-by-default" solution.

For 2, adding the Scripts subdirectory seems reasonable.

FWIW, Window used to have *very* severe restrictions on the maximum length of PATH, as well as gratuitously long names for standard executable file locations. This made conscientious developers understandably reluctant to mess with PATH, because adding to the start could break other elements of the user's system, while adding to the end wasn't reliable.

This is much less of an issue these days, as Windows is a lot more tolerant of ridiculously long PATH definitions.
msg161533 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-05-24 21:57
> 2. Yes, only the installation directory, because that's the only  
> directory we create. Scripts is created by distutils/packaging, but  
> perhaps we could add it since it is widely used. Anyone have an  
> opinion?

Fine with me. To create an empty directory, an entry into the CreateFolder
table needs to be made. This isn't yet supported in msilib.py, but should
be a method on Directory.
msg161539 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-05-25 00:11
I'm strongly opposed to enabling this by default at least for 3.3, but does anyone think something like this dialog http://i.imgur.com/18zPD.png be helpful? After choosing the directory to install to and before choosing the features, it's a simple dialog explaining that the Path feature is available and what it does.

Attached is the patch.
msg161581 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2012-05-25 14:22
Chris Lambacher

On Wed, Apr 25, 2012 at 10:50 AM, Martin v. Löwis  added the comment:

> lambacck: I'm -1, but I'm willing to yield ...
> regular users won't have to deal with negative
> consequences that enabling this by default may have.

> I'm quite opposed to your proposed conditional approach;
> I think this will be highly confusing to users.

Could you clarify what you think will be confusing?  I see (a slight
variant of) Chris Lambacher's conditional approach as the obvious best
choice, if it is feasible.

(1)  The default is "What you are already doing."
(2)  If this is your only install, then assume you do want it on the
path, as many newbies would.

The only tweak is that if there is already a path to an
*older-but-compatible* version, then its path entry should be replaced
(not added to).

Or are you concerned that there may be differences of opinion on
whether or not 3.4 is sufficiently compatible with 3.3, and that
making the default context-sensitive will cause this to be Python's
problem, rather than the application's?

-jJ
msg161585 - (view) Author: Jim Jewett (Jim.Jewett) Date: 2012-05-25 15:18
On Thu, May 24, 2012 at 8:11 PM, Brian Curtin
<brian@python.org> added the comment:

> does anyone think something like this dialog http://i.imgur.com/18zPD.png be helpful?

yes.

> After choosing the directory to install to and before choosing
> the features, it's a simple dialog explaining that the Path
> feature is available and what it does.

But it might make sense to put that on the same screen where you
choose whether or not to check the box, even if that box (ands it
checkedness state) also gets carried over to a choose-all-options
screen.
msg163529 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-06-23 03:55
So I have a patch that does most of what my previous message shows, but I can't seem to complete it. I don't know if I'm misunderstanding something or this just can't be done, but I could use the help of someone who understands MSI things much better than I can.

Attached is the patch which makes this (http://i.imgur.com/415Y1.png) screen possible. The problem is that I can't seem to hook up the Yes and No buttons to set the path feature to install or not on the next screen, the Feature selection page.

http://ubuntuone.com/1GfW3hasOIDydQEAweOoKr is a link to an installer built with that patch if anyone wants to click through and it and see if it's worth adding in that form.
msg163538 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-23 07:24
These things are best studied with msiexec ... /l*v python.log, then inspecting python.log. Without looking at the trace, I'd expect that the actual installation run doesn't inherit ModifyPath from the UI run.

The installer runs actually twice - once in the user account, performing the UI sequence and collecting all information. Then in the context of the installer service, running the execute sequence to modify the system. Information is passed in properties. However, not all properties are passed, only secure properties (which I believe must be UPPERCASE, in addition to being listed as a secure property).

However, I really recommend to not introduce another secure property, but instead use a custom action, see

http://www.advancedinstaller.com/user-guide/qa-conditional-feature.html

Write a VB script, and call Session.FeatureRequestState.

As yet an alternative, and possibly the best one, there is an AddLocal ControlEvent, see

http://msdn.microsoft.com/en-us/library/windows/desktop/aa367537(v=vs.85).aspx

Associating this event with the "Yes" button should make the feature selected. Note that you can have multiple control events for a button, so you can proceed to the next dialog after having this control event.
msg164630 - (view) Author: Jason Spiro (jasonspiro) Date: 2012-07-03 23:38
Just a few comments on your new UI design <http://i.imgur.com/415Y1.png>:

== Suggestion 1 ==

It seems, from your screenshot, that you plan to hide the [ Next > ]
and [ Cancel ] buttons, and show your [ Yes ] and [ No ] buttons
instead.  This is doing something completely unexpected to the user.
I've used hundreds or thousands of Windows installers and IIRC never
seen such a thing.

Instead, may I suggest a checkbox:

    [x] Prepend the Python folder to the PATH environment variable (recommended)

and leaving the [ Next > ] and [ Cancel ] buttons as-is.

== Suggestion 2 ==

Better yet, get rid of the screen which talks about changing the PATH
entirely.  Instead, on the feature-selection screen, make the
prepend-Python-to-PATH option be selected by default.

Why not try implementing this suggestion in the next 3.3.0 beta?  Then
you can see if the tech-support burden increases or decreases.
msg164635 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-07-04 04:03
> == Suggestion 1 ==

I don't think it's that unexpected. I certainly didn't come up with the idea myself - I've seen them before. Surely it might be new to some people, but is it confusing? For one, we think it's an option users should know about. It's also an option that you should explicitly enable. The yes/no seemed like an easy way to ask a yes/no question if you want it.

> Instead, may I suggest a checkbox:

My first iterations of this patch used a checkbox in an additional window. I guess it's a possibility. If I can even figure out how to make any of this actually work, I'll try a version with a checkbox.

> == Suggestion 2 ==

We can't make it the default. This has been explained on this issue, other issues around the tracker, on python-dev, and in a lot of other places. Believe me, as one of the biggest Python 3 advocates you can find, making Python 3 the default installation is not the right move here. If it's on by default, it absolutely will cause problems because people just click right through the installer and their system will be modified in a way that they don't want and potentially won't know how to undo. This type of change has to be exposed in a loud and non-default way to start.
msg164660 - (view) Author: Jason Spiro (jasonspiro) Date: 2012-07-04 21:22
I'm glad you're willing to consider using a checkbox.  It seems to fit
better with the wizard paradigm, where there are always [ < Back ], [
Next > ], and [ Cancel ] buttons onscreen.

OK, I acknowledge that a lot of third-party software still depends on
Python 2.  Fine.  Why not modify the Python 3 installer to add Python
3 to the *end* of the PATH variable, not the beginning?  Then I think
you could safely modify the PATH variable by default.
msg164661 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-07-04 21:40
We don't need to stay with some paradigm if it's not the best way. If I can get any of these ways to work, I may post some type of survey on python-dev.

Adding to the end wouldn't make this much of a feature. Most users have already put another Python into their path, so if they decide they want to add 3.3 to it, this option barely helps them.

Anyway, just about everything relating to this feature has been discussed on the above mentioned lists over a long period of time. The feature is implemented as is, it has already been released, and it's staying that way for 3.3. All we can do is tweak the GUI.
msg164662 - (view) Author: Jason Spiro (jasonspiro) Date: 2012-07-04 21:50
Adding Python to the end of the PATH would very much help Windows
non-experts who don't even know what a PATH is.

IMO, when Python 3.4 comes out, it'd make sense add Python to the end
of the PATH by default.  This'd help those non-experts a lot.

On 7/4/12, Brian Curtin <report@bugs.python.org> wrote:
>
> Brian Curtin <brian@python.org> added the comment:
>
> We don't need to stay with some paradigm if it's not the best way. If I can
> get any of these ways to work, I may post some type of survey on
> python-dev.
>
> Adding to the end wouldn't make this much of a feature. Most users have
> already put another Python into their path, so if they decide they want to
> add 3.3 to it, this option barely helps them.
>
> Anyway, just about everything relating to this feature has been discussed on
> the above mentioned lists over a long period of time. The feature is
> implemented as is, it has already been released, and it's staying that way
> for 3.3. All we can do is tweak the GUI.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3561>
> _______________________________________
>
msg174645 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-03 16:26
Can this issue be closed?  If there are still disagreements about the UI or UX, it could be a separate 3.4 report.
msg174657 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-11-03 18:04
As Eric says: any further issues with this change should be reported separately.
History
Date User Action Args
2012-11-03 18:04:23loewissetstatus: open -> closed

messages: + msg174657
2012-11-03 16:26:21eric.araujosetmessages: + msg174645
2012-08-14 03:45:13r.david.murraylinkissue7231 superseder
2012-07-04 21:50:31jasonspirosetmessages: + msg164662
2012-07-04 21:40:18brian.curtinsetmessages: + msg164661
2012-07-04 21:22:15jasonspirosetmessages: + msg164660
2012-07-04 04:03:30brian.curtinsetmessages: + msg164635
2012-07-03 23:38:10jasonspirosetmessages: + msg164630
2012-06-23 07:24:37loewissetmessages: + msg163538
2012-06-23 03:55:15brian.curtinsetstatus: closed -> open
files: + path_option.diff
messages: + msg163529
2012-05-25 15:18:46Jim.Jewettsetmessages: + msg161585
2012-05-25 14:22:12Jim.Jewettsetmessages: + msg161581
2012-05-25 00:13:59sridsetnosy: - srid
2012-05-25 00:11:32brian.curtinsetfiles: + news_dialog.diff

messages: + msg161539
2012-05-24 21:57:43loewissetmessages: + msg161533
2012-05-24 21:37:09ncoghlansetmessages: + msg161532
2012-05-24 21:36:55pekka.klarcksetmessages: + msg161531
2012-05-24 21:28:13brian.curtinsetmessages: + msg161530
2012-05-24 21:00:21pekka.klarcksetnosy: + pekka.klarck
messages: + msg161528
2012-04-25 15:42:50eric.araujosetmessages: + msg159305
2012-04-25 15:20:50pitrousetmessages: + msg159298
2012-04-25 15:11:51lambaccksetmessages: + msg159295
2012-04-25 14:50:01loewissetmessages: + msg159289
2012-04-25 14:35:53lambaccksetnosy: + lambacck
messages: + msg159288
2012-04-25 13:26:02brian.curtinsetstatus: open -> closed
resolution: fixed
messages: + msg159283

stage: commit review -> resolved
2012-04-25 13:13:09python-devsetnosy: + python-dev
messages: + msg159280
2012-04-25 06:58:37loewissetmessages: + msg159259
stage: patch review -> commit review
2012-04-18 22:43:53brian.curtinsetfiles: + issue3561_v3.diff

messages: + msg158680
2012-04-18 22:08:35eric.araujosetmessages: + msg158672
2012-04-18 04:48:20brian.curtinsetfiles: + issue3561_v2.diff

messages: + msg158588
2012-04-09 22:59:25brian.curtinsetmessages: + msg157921
2012-04-09 22:05:47loewissetmessages: + msg157911
2012-04-09 21:52:12loewissetmessages: + msg157909
2012-04-09 20:47:48brian.curtinsetmessages: + msg157897
2012-04-09 20:45:06brian.curtinsetmessages: + msg157895
2012-04-09 20:36:37pitrousetnosy: + pitrou
messages: + msg157893
2012-04-09 20:31:26brian.curtinsetfiles: - prependpath_in-progress.diff
2012-04-09 20:26:57Jim.Jewettsetnosy: + Jim.Jewett
messages: + msg157892
2012-04-07 15:45:42brian.curtinsetkeywords: + needs review
files: + issue3561.diff
messages: + msg157735

stage: patch review
2012-03-30 03:03:14jdigitalsetnosy: + jdigital
messages: + msg157124
2012-02-20 02:34:01brian.curtinsetfiles: + prependpath_in-progress.diff
assignee: brian.curtin
messages: + msg153761

keywords: + patch
2012-02-05 22:02:58helder-magalhaessetmessages: + msg152711
2012-02-05 21:11:38loewissetmessages: + msg152709
versions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.4
2012-02-05 20:43:45brian.curtinsetmessages: + msg152707
2012-02-05 20:40:41helder-magalhaessetnosy: + helder-magalhaes

messages: + msg152706
versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.4
2011-08-11 22:16:35AaronRsetnosy: + AaronR
2011-07-31 15:16:52r.david.murraylinkissue12664 superseder
2011-07-11 15:35:20eric.araujosetnosy: + eric.araujo
2011-04-25 10:51:56jonathan.hartleysetnosy: + jonathan.hartley
2011-04-24 16:59:34sridsetmessages: + msg134333
2011-04-24 10:07:24ncoghlansetnosy: + brian.curtin
messages: + msg134328
2011-04-24 09:43:43ncoghlansetstatus: closed -> open
versions: + Python 3.3
nosy: + ncoghlan

messages: + msg134326

resolution: wont fix -> (no value)
2011-04-23 15:47:40eric.araujolinkissue9228 superseder
2011-04-23 15:37:13eric.araujolinkissue482531 superseder
2011-01-28 17:58:45giampaolo.rodolasetnosy: + giampaolo.rodola
2009-09-16 01:19:55sridsetnosy: + srid
2009-03-30 19:06:40loewislinkissue5608 superseder
2008-09-02 11:35:55amaury.forgeotdarclinkissue3733 superseder
2008-08-15 23:01:12loewissetmessages: + msg71190
2008-08-15 21:22:04jasonspirosetmessages: + msg71185
2008-08-15 18:03:39loewissetstatus: open -> closed
resolution: wont fix
messages: + msg71174
2008-08-15 17:16:22jasonspirocreate