-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows installer should add Python and Scripts directories to the PATH environment variable #47811
Comments
The Python Windows installer[1] should automatically add the Python and This issue was discussed at http://nabble.com/Why-does-Python-never-add- ^ [1]. The installer is generated by the code at |
I still don't think such a change should be made, hence I reject this |
Martin, at the time I read the python-list thread, I didn't pay any I already know the basic ideas about creating MSIs with Wise from a Here are the rough notes I've made up so far on how to do this:
Another difficult part is the UI. Then there's the issue of switching Remember that Windows Installer cannot undo its PATH changes at
P.S. Would you prefer to discuss this by something more synchronous P.P.S. Now that I have realized how complicated Python installation 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 |
Completely disagree. Adding something to PATH is nearly unacceptable In principal, uninstallation should completely undo installation. There
To me, any change to PATH is a problem... (I really think that software
I don't think this can be done for 2.6, so there is no need for
I think this is incorrect. You cannot uninstall the path through If such a solution was designed, there would still be many questions,
|
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. |
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. |
ActivePython 2.x has it on by default. |
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 |
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. |
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. |
@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... :-) |
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. |
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. |
Attached is bpo-3561.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. |
@brian -- to clarify, (1) Does bpo-3561.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? |
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 unlinked the old diff. bpo-3561.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. |
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. |
You are misinterpreting the UI. The list is not of "installable components", |
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. |
Agreed. I will work up a more friendly text to go along with the feature. |
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 |
A minor thing: The capitalization of the feature names is inconsistent. |
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. |
Brian: The patch is fine, please apply. |
New changeset 4e9f1017355f by Brian Curtin in branch 'default': |
Now that the feature is in, I'm going to track the few places we need to document it in bpo-14668. |
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: 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. |
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. |
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. |
To put things in perspective, the default under POSIX ("make install") |
[Jeff Dean]
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. |
I found about this enhancement via Python Insider blog post [1] that also asked adding comments to this issue. Here are mine:
[1] http://blog.python.org/2012/05/recent-windows-changes-in-python-33.html |
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. |
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. |
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. |
Fine with me. To create an empty directory, an entry into the CreateFolder |
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. |
Chris Lambacher On Wed, Apr 25, 2012 at 10:50 AM, Martin v. Löwis added the comment:
Could you clarify what you think will be confusing? I see (a slight (1) The default is "What you are already doing." The only tweak is that if there is already a path to an Or are you concerned that there may be differences of opinion on -jJ |
On Thu, May 24, 2012 at 8:11 PM, Brian Curtin
yes.
But it might make sense to put that on the same screen where you |
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. |
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. |
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 > ] Instead, may I suggest a checkbox:
and leaving the [ Next > ] and [ Cancel ] buttons as-is. == Suggestion 2 == Better yet, get rid of the screen which talks about changing the PATH Why not try implementing this suggestion in the next 3.3.0 beta? Then |
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.
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.
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. |
I'm glad you're willing to consider using a checkbox. It seems to fit OK, I acknowledge that a lot of third-party software still depends on |
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. |
Adding Python to the end of the PATH would very much help Windows IMO, when Python 3.4 comes out, it'd make sense add Python to the end On 7/4/12, Brian Curtin <report@bugs.python.org> wrote:
|
Can this issue be closed? If there are still disagreements about the UI or UX, it could be a separate 3.4 report. |
As Eric says: any further issues with this change should be reported separately. |
New changeset a9d34685ec47 by Brian Curtin in branch '2.7': |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: