Re: [Python-Dev] New Windows installer for Python 3.5
On 4 January 2015 at 22:56, Steve Dower wrote: >> Also, what happens now with setting PATH? Is Python (and the scripts >> directory) added to PATH by default? If so, what happens when you >> install 2 versions of Python? > > Yes, and in general the later installed version will win and system-wide > installs always beat per-user installs. As I mentioned above, using py.exe > with a parameter or shebang line is the most reliable way to get the version > you want. Hmm, that's unfortunate. Normally I leave "Add to PATH" off for all but one installation. I certainly don''t want all versions on there - I've had too many issues with running something like py.test and finding it's running Python 3.3 because I didn't install it into Python 3.4. I'm pretty sure we'll get bug reports "I installed Python 3.5.1 but I'm still getting Python 3.5" from the per-user behaviour. And saying "don't do that" isn't a fix, nor is blaming Microsoft, really. Unfortunately, I don't see a good solution here. >> Also, how does the launcher py.exe fit into the picture? Is it still >> installed into the Windows directory? What about for a user install? >> Are Python scripts associated with the launcher, and if so, how does >> it pick up the version you selected as default? > > py.exe is more important than ever. It's still installed into the Windows > directory for all-user installs, and into the Python directory for > just-for-me. It's installed in a way that will make upgrades more reliable > (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all > the file associations go straight to the launcher. The biggest problem here is that py.exe doesn't help in the slightest with script wrappers like pip.exe, virtualenv.exe, py.test.exe, ipython.exe ... I've actually drifted away from using py.exe because of this. Having just the interpreter special cased isn't really good enough. (I know there's py -m pip, but it's not easy to get people to use this...) I think it's really important to only have one Python on your PATH, so just dumping everything there by default, particularly if user installs get pushed to the end and don't have precedence, is a bad experience. > The default Python for the launcher seems to be 2.7 if it's there and the > latest version if not (though I could be wrong). Shebang lines are the best > way to choose a specific version. Yes, that's a very bad default IMO. It was probably reasonable at the time, but it should be fixed now - at least to a simple "the latest version". Getting a user who's just installed Python 3.5 (with a system Python 2.7 present) to edit an ini file in C:\Windows\System32 just to use his new version is *not* a good user experience. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 5 January 2015 at 01:20, Steve Dower wrote: > I think this means the best way to make multiple versions work properly is to > rename python.exe to python3.5.exe, then install the launcher as python.exe > and python3.exe (with some logic to look at its own name) so it can resolve > the right version. Maybe we can even extend the launcher to resolve launchers > in Scripts (pip.exe, etc.) and have consistent rules there too? This was a big debate over on distutils-sig. I advocated "py -m pip" for portable use, but got basically nowhere. People want "pip" to work, for compatibility with Unix (and hence ease of documentation). If we can't get PATH sorted out, we need to do something about this, IMO. I don't know what (believe me, I tried to find a solution) unfortunately. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
> On Jan 5, 2015, at 3:13 AM, Paul Moore wrote: > >> py.exe is more important than ever. It's still installed into the Windows >> directory for all-user installs, and into the Python directory for >> just-for-me. It's installed in a way that will make upgrades more reliable >> (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all >> the file associations go straight to the launcher. > > The biggest problem here is that py.exe doesn't help in the slightest > with script wrappers like pip.exe, virtualenv.exe, py.test.exe, > ipython.exe ... I've actually drifted away from using py.exe because > of this. Having just the interpreter special cased isn't really good > enough. (I know there's py -m pip, but it's not easy to get people to > use this...) Won’t script wrappers use whatever version they were installs against? Or do you mean the “installed” version might be 3.5 for ``pip.exe`` even though there’s a 3.5.1 for ``pip.exe`` on the PATH? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 04/01/2015 22:56, Steve Dower wrote: Paul Moore wrote: Overall, this looks good. One question - will it be possible to install both 32-bit and 64-bit Python on the same machine? Currently, you need a custom install to do this (as the default directory doesn't include the architecture) and IIRC there's some oddness around install order. It would be nice if installing both versions were a supported option, both for the "default" install and in custom installs. Yes, the default install directories on the first page are different for 32-bit and 64-bit (either "Program Files [(x86)]" or "Python35[-32]"). The default value on the customize page is currently always C:\Python35, and so you'll need to change it if you're doing custom installs, but that's easy to add the "-32" by default. (I used a -32 suffix because it matches the py.exe option.) Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python? Yes, and in general the later installed version will win and system-wide installs always beat per-user installs. As I mentioned above, using py.exe with a parameter or shebang line is the most reliable way to get the version you want. In case it's not clear, I'm thinking of the impact on build machines, which often have multiple versions, in both 32- and 64-bit forms, installed simultaneously (but can also be used as a "normal" development machine, and for that purpose will want a selected Python version as the default one. You should see my dev machines :) Most have 2.5, 2.6, 2.7 32-bit and 64-bit, 3.0, 3.1, 3.2, 3.3 32-bit and 64-bit, 3.4 32-bit and 64-bit, IronPython and often PyPy, Anaconda or Canopy. So I'm being fairly selfish when I try and make the multiple-versions scenario work better, but it will benefit everyone. Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default? py.exe is more important than ever. It's still installed into the Windows directory for all-user installs, and into the Python directory for just-for-me. It's installed in a way that will make upgrades more reliable (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all the file associations go straight to the launcher. The default Python for the launcher seems to be 2.7 if it's there and the latest version if not (though I could be wrong). Shebang lines are the best way to choose a specific version. Incidentally, whoever came up with the py.exe launcher deserves a medal. It's made dealing with multiple versions amazingly easy. If I'm reading this correctly it means that py.exe gets picked up from PATH so it could be 32 or 64 bit. Does this mean that the launcher could be or needs enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be done about pyw.exe, perhaps you (plural) can throw some light on this for me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 5 January 2015 at 08:40, Donald Stufft wrote: >> The biggest problem here is that py.exe doesn't help in the slightest >> with script wrappers like pip.exe, virtualenv.exe, py.test.exe, >> ipython.exe ... I've actually drifted away from using py.exe because >> of this. Having just the interpreter special cased isn't really good >> enough. (I know there's py -m pip, but it's not easy to get people to >> use this...) > > Won’t script wrappers use whatever version they were installs against? Or do > you mean the “installed” version might be 3.5 for ``pip.exe`` even though > there’s a 3.5.1 for ``pip.exe`` on the PATH? What I mean is that if you have Python 3.4 and Python 3.5 installed, and pip.exe is in the Scripts directory of each, then which pip.exe you get (and hence which Python you install into) if you just type "pip install xxx" depends on your PATH. Steve is in essence saying that it's not possible to sanely manage PATH as part of the new installer, but that py.exe makes that unnecessary. My point is that while py handles the interpreter, it doesn't handle things like pip (unless we change the standard usage instructions to say "py -m pip" is the supported approach on Windows). Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 01/04/2015 02:56 PM, Steve Dower wrote: > ChrisA wrote: >> You talk of installing by default into Program Files, and having a >> separate per-user installation mode. How do these two installation >> targets interact? Suppose someone installs 3.5 globally, then installs >> 3.6 for self only? Or installs 3.5.1 for self only? I would normally >> expect a per-user installation to trump a global one, but this could >> make for a lovely dep-hell on a system that's used by one person, who >> then isn't sure what was installed as admin and what wasn't. > > Yeah, it gets a little messy, especially if you keep adding all the > Python versions to PATH (Windows will always put per-user PATH entries > at the end). The py.exe launcher handles this best, and the system > version will always be found first. py.exe should *not* follow this behavior. User installs should be searched first, then system installs -- otherwise, what's the point in having a user-install? Filling up the gobs of disk-space we now have available? -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
Mark Lawrence wrote: > If I'm reading this correctly it means that py.exe gets picked up from PATH so > it could be 32 or 64 bit. Does this mean that the launcher could be or needs > enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be > done > about pyw.exe, perhaps you (plural) can throw some light on this for me. We only ever install a 32-bit launcher (including with the current installer, though it doesn't quite work properly), so this isn't really an issue. To explicitly request a 32-bit interpreter you can pass "-3.5-32" - without the "-32" suffix you'll get 64-bit if it's there and 32-bit otherwise. Paul Moore wrote: > Steve is in essence saying that it's not possible to sanely manage PATH as > part > of the new installer, but that py.exe makes that unnecessary. It's actually not possible to sanely manage PATH from any installer - it really needs to be handled by a user directly (though I can't ever bring myself to tell anyone to use the UI for it). The old installers were less susceptible because they didn't support per-user installs, but you'd still get the "last install Python wins" behaviour. > My point is that while py handles the interpreter, it doesn't handle things > like > pip (unless we change the standard usage instructions to say "py -m pip" is > the > supported approach on Windows). Or we make pip3.5.exe launch against 3.5 and pip.exe and pip3.exe behave like the launcher, regardless of where they run from. For example, say I have Python 3.5 and Python 3.6 installed and PATH=C:\Python35;C:\Python35\Scripts;C:\Python36;C:\Python36\Scripts;... (yes, those are the 'wrong' way around). If I just type "pip" it will run C:\Python35\Scripts\pip.exe, which may or may not be what I expect. If pip behaved like the launcher, it would find the latest installed version (3.6) and launch pip3.6.exe, which would always run against C:\Python36\python.exe. (How does it do this? No idea yet. Technical details...) This might also mean you could write "pip -3.5 install ..." to run against a specific version, but that doesn't have to be supported if it's likely to break scripts by stealing an argument. Since we'll install "pip", "pip3" and "pip3.5", the options are already there. Would we need "pip3.5-32" as well? This could get out of hand pretty quickly. Perhaps the launcher could include "usepy -3.5" to update the user's PATH for the current session? Would that get any more use? I don't know, but it feels unlikely. There have been multiple requests for the Add to PATH option to be enabled by default in the installer, but frankly it concerns me too much to do so. There are too many effects that most users won't expect. Cheers, Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
Ethan Furman: > On 01/04/2015 02:56 PM, Steve Dower wrote: > >> ChrisA wrote: >>> You talk of installing by default into Program Files, and having a >>> separate per-user installation mode. How do these two installation >>> targets interact? Suppose someone installs 3.5 globally, then >>> installs >>> 3.6 for self only? Or installs 3.5.1 for self only? I would normally >>> expect a per-user installation to trump a global one, but this could >>> make for a lovely dep-hell on a system that's used by one person, who >>> then isn't sure what was installed as admin and what wasn't. >> >> Yeah, it gets a little messy, especially if you keep adding all the >> Python versions to PATH (Windows will always put per-user PATH entries >> at the end). The py.exe launcher handles this best, and the system >> version will always be found first. > > py.exe should *not* follow this behavior. User installs should be searched > first, then system installs -- otherwise, what's the point in having a > user-install? Filling up the gobs of disk-space we now have available? Typo on my part. The py.exe launcher will always find the *user* install first. Searching PATH will always find the system version first. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 05/01/2015 17:09, Steve Dower wrote: Paul Moore wrote: Steve is in essence saying that it's not possible to sanely manage PATH as part of the new installer, but that py.exe makes that unnecessary. It's actually not possible to sanely manage PATH from any installer - it really needs to be handled by a user directly (though I can't ever bring myself to tell anyone to use the UI for it). The old installers were less susceptible because they didn't support per-user installs, but you'd still get the "last install Python wins" behaviour. Something that's help keep me slightly sane is the Rapid Environment Editor http://www.rapidee.com/en/about. I'm sure there are plenty of other choices but it does what I need. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
tl;dr We should have "Add this Python to PATH" as a user choice on the initial installer screen, applicable to whichever install type the user chooses. Details as to why are below. On 5 January 2015 at 17:09, Steve Dower wrote: > Paul Moore wrote: >> Steve is in essence saying that it's not possible to sanely manage PATH as >> part >> of the new installer, but that py.exe makes that unnecessary. > > It's actually not possible to sanely manage PATH from any installer - it > really needs to be handled by a user directly (though I can't ever bring > myself to tell anyone to use the UI for it). The old installers were less > susceptible because they didn't support per-user installs, but you'd still > get the "last install Python wins" behaviour. Agreed. But the current behaviour has "Add Python to PATH" as an explicit option for the user to choose (I can't recall whether the default is still not to do so, or if it was changed in 3.4, but that's a minor issue). People (the minority) who install multiple Pythons should (IMO) only set this flag on for one Python at most - and I don't feel obliged to include any special behaviour for anyone who doesn't follow that rule. The new installers, with their "One-Click" installs, don't give that choice. So they are left having to juggle the multiple path entry problem, without enough input from the user on what he/she wants. For myself, I'll probably have to use the custom install to get the control I want. But that's suboptimal, as I probably *want* to use the new locations, and having to override the "Custom" default of C:\Python35 to specify "Program Files" is a nuisance. And I bet I'll install a 32-bit Python in "C:\Program Files" rather than "C:\Program Files (x86)" at least once, and probably more than once... Maybe all that's needed is to have an extra checkbox on the first page saying "Add this Python to PATH" (doesn't matter whether it's on or off by default). We can warn if it's set on when there's another Python already on PATH, and warn more vigorously (possibly even an error) if the other Python will take precedence over the one we're installing. But I don't think you can avoid giving the user the choice of whether to put Python on PATH. There are too many bad corner cases to let the installer guess.[1] >> My point is that while py handles the interpreter, it doesn't handle things >> like >> pip (unless we change the standard usage instructions to say "py -m pip" is >> the >> supported approach on Windows). > > Or we make pip3.5.exe launch against 3.5 and pip.exe and pip3.exe behave like > the launcher, regardless of where they run from. That would be a change to pip (the wrapper generation code for wheels) and setuptools (the equivalent code for sdist installs). The launcher behaviour is more complex to handle, but could be done (at least in the case of wheels - that uses the distil wrapper code which doesn't work like the launcher but Vinay could comment on whether that would be something that could be added). I'm not against this, it's been mentioned in the past for pip but no-one has had the time or inclination to work on it. The alternative is to special-case pip and I'm strongly -1 on that - this is a general issue for all wrappers. > For example, say I have Python 3.5 and Python 3.6 installed and > PATH=C:\Python35;C:\Python35\Scripts;C:\Python36;C:\Python36\Scripts;... > (yes, those are the 'wrong' way around). If I just type "pip" it will run > C:\Python35\Scripts\pip.exe, which may or may not be what I expect. As I say, I don't really care much about supporting this case - my view is that the user should have only added *one* of the Python installations to PATH. > If pip behaved like the launcher, it would find the latest installed version > (3.6) and launch pip3.6.exe, which would always run against > C:\Python36\python.exe. (How does it do this? No idea yet. Technical > details...) One hard problem - if pip is only installed in Python 3.5, it would not be able to import pip from the Python 3.6 interpreter because it's simply not present. I'm not sure this is soluble. > This might also mean you could write "pip -3.5 install ..." to run against a > specific version, but that doesn't have to be supported if it's likely to > break scripts by stealing an argument. Since we'll install "pip", "pip3" and > "pip3.5", the options are already there. > > Would we need "pip3.5-32" as well? This could get out of hand pretty quickly. > Perhaps the launcher could include "usepy -3.5" to update the user's PATH for > the current session? Would that get any more use? I don't know, but it feels > unlikely. There have been multiple requests for the Add to PATH option to be > enabled by default in the installer, but frankly it concerns me too much to > do so. There are too many effects that most users won't expect. If we assume there's never more than one Python installation on PATH (and make it easy for users to stick to this) then
Re: [Python-Dev] New Windows installer for Python 3.5
Paul Moore wrote: > tl;dr We should have "Add this Python to PATH" as a user choice on the initial > installer screen, applicable to whichever install type the user chooses. > Details > as to why are below. I agree. I'll work this up before alpha 1. (FWIW, it defaults to unselected.) Displaying a warning about other Pythons already being on the path at this point is trickier, but I can probably figure something out. > For myself, I'll probably have to use the custom install to get the control I > want. But that's suboptimal, as I probably *want* to use the new locations, > and > having to override the "Custom" default of C:\Python35 to specify "Program > Files" is a nuisance. And I bet I'll install a 32-bit Python in "C:\Program > Files" rather than "C:\Program Files (x86)" at least once, and probably more > than once... Inclined to agree, and it is possible to make the default on the customise page switch with the Install as Administrator checkbox until it's been manually edited. My main concern is people who want it the old way, but they may not actually exist. Perhaps making the old way trickier is the best way to flush them out sooner... Cheers, Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 5 January 2015 at 21:47, Steve Dower wrote: > Paul Moore wrote: >> tl;dr We should have "Add this Python to PATH" as a user choice on the >> initial >> installer screen, applicable to whichever install type the user chooses. >> Details >> as to why are below. > > I agree. I'll work this up before alpha 1. (FWIW, it defaults to unselected.) Cool. Would you make the new installer keep "Add to PATH" as unselected by default? I got the impression that the "One Click" installs would add to PATH, making it reasonable to have the checkbox selected by default. > Displaying a warning about other Pythons already being on the path at this > point is trickier, but I can probably figure something out. No big deal if you can't. It's a "nice to have" but not essential. >> For myself, I'll probably have to use the custom install to get the control I >> want. But that's suboptimal, as I probably *want* to use the new locations, >> and >> having to override the "Custom" default of C:\Python35 to specify "Program >> Files" is a nuisance. And I bet I'll install a 32-bit Python in "C:\Program >> Files" rather than "C:\Program Files (x86)" at least once, and probably more >> than once... > > Inclined to agree, and it is possible to make the default on the customise > page switch with the Install as Administrator checkbox until it's been > manually edited. My main concern is people who want it the old way, but they > may not actually exist. Perhaps making the old way trickier is the best way > to flush them out sooner... Having said this, if I can choose "Add to PATH" without needing a custom install, then probably the only reason I'd be likely to want a custom install would be to change the path, so the value of the default is not such a big deal for me personally. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
