[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Jason Spiro added the comment: 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 wrote: > > Brian Curtin 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 > <http://bugs.python.org/issue3561> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Jason Spiro added the comment: 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. -- ___ Python tracker <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Jason Spiro added the comment: 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. -- ___ Python tracker <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
Jason Spiro added the comment: > Can you provide a patch? Unfortunately not. I still don't think it's worth fixing this bug. :) I think you should document it in the bdist_wininst documentation then close this bug as "won't fix due to lack of volunteer resources". That way the problem will be documented both here and in that documentation, but nobody need spend the time to fix such a minor bug. Or at least you should lower this bug's priority to the lowest setting. -- ___ Python tracker <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
Jason Spiro <[EMAIL PROTECTED]> added the comment: Attaching testcase. It's basically just some sample code from the distutils documentation. Added file: http://bugs.python.org/file11177/testcase.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
New submission from Jason Spiro <[EMAIL PROTECTED]>: == Summary == Installers made by bdist_wininst never set EstimatedSize in the Windows registry. So Windows makes an estimate[1] of the installed software's size so the Add/Remove Programs control panel can tell users how much space the software is are taking up. Windows overestimates the size: it estimates the size as equal to the size of the entire C:\Python directory. Nowadays, disk space is cheaper than ever, so I assume it's uncommon for people to try to uninstall software to gain space back. So I do not think it's worth fixing this bug. Does anyone think it *is* worth fixing? == Steps to repro == You *must* be running Windows XP or higher to repro this.[2] I used Python 2.5 (which I installed using the MSI installer) but I would be extremely surprised if this was already fixed in a newer Python's distutils. - Download the attached testcase.zip - Unzip it to a temp directory - From the temp directory, run the commands: setup.py bdist_wininst cd dist foo-1.0.win32.exe - Click on Start Menu > Settings > Control Panel > Add/Remove Programs - Scroll down to "Python 2.5 foo-1.0". == Actual results == - The "Size" column on the right says 46.86MB (that's the size of my entire "C:\Python 2.5" directory.) == Expected results == - The "Size" column on the right should say something close to 0.1 megabytes. == Suggested fix == - When creating an installer, bdist_wininst should look at the total size of all files to install, multiply that number by 3 (a reasonable estimate of the total size the .pyc and .pyo files will take up), and make the installer set the EstimatedSize[3] in the registry to that number. == Footnotes == ^ [1]. See the blog entry "How does Add/Remove Programs get the size and other information?" by Raymond Chen at http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx for info on the algorithm Windows uses. ^ [2]. Versions of Windows older than XP never try to estimate the size of installed programs. ^ [3]. This is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\(application descriptor)\EstimatedSize and should be a DWORD representing the number of kilobytes the software takes up, according to http://forum.installsite.net/?showtopic=698#entry12501 -- components: Distutils messages: 71554 nosy: jasonspiro severity: normal status: open title: it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Jason Spiro <[EMAIL PROTECTED]> added the comment: 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. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
New submission from Jason Spiro <[EMAIL PROTECTED]>: 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/ -- components: Installation, Windows messages: 71172 nosy: christian.heimes, jasonspiro, loewis severity: normal status: open title: Windows installer should add Python and Scripts directories to the PATH environment variable type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
