Adding python to Windows. Was :Re: Make py.exe default to Python 3
On 16 Mar 2016 17:47, "Steve Dower" <steve.dower@python.org> wrote:
The uninstall problem is actually that "python" would stop working
completely in that case, and it's not necessarily obvious why or how to fix it.
The leave-behind problem doesn't really matter as the directory is not
searched if it doesn't exist, but we also don't leave behind entries added by the installer. A user who customizes their own PATH will obviously need to manually remove the entry, but that's a manual action both times so I don't see any concern there.
At one point I was trying to convince the Windows team to add a global
"python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen? That would be amazing! Then I guess all the major OSes would ship with Python making simple Python scripts portable and solving a lot of the problems that pyinstaller/py2exe try to solve. Can you expand on how that might work? The detail affects which problems it would solve. Would it be like the system Python on OSX? -- Oscar
On 16Mar2016 1115, Oscar Benjamin wrote:
So my main concern about getting Python shipping with Windows has always been long-term compatibility. Basically, we're in the same category as LTS RHEL: whatever ships now *will still be 100% compatible with what we are shipping in ten years time* (yes, that's an aspiration more than a guarantee, but it certainly rules out 3.n->3.(n+1) upgrades). As a result, if Python did ship in Windows, I'd be trying really hard to make it an internal implementation detail to discourage people from ever relying on it. As Nick Coghlan said when I last chatted with him about this, "please, please, learn from our mistakes" :) So the idea that I was working on was effectively the py.exe launcher, but taking over the global "python" name (and probably "python3"/"python2"), and with the addition of useful error messages (i.e. with URLs or extra tools) for when you try and run "python" without having installed it. And also add proper support for configuring defaults and active virtual environments (which are both in the current py.exe launcher, but seem to not be well known). Shebang support would stick around and be encouraged, along with specifying Python language versions such that scripts will run with the correct version on new machines. The install step may be painful the first time, but since Python 3.5+ does not require admin privileges, it should be quick and easy for most people. I don't see us going out of our way to update legacy versions to do this - they'll continue to need admin rights. This would obviously be a big and unexpected change for users, but it seems to be the most viable way of making Python universally available without locking into a specific version for 10+ years or essentially forking a "Microsoft Python" that ends up being very different from CPython releases. And the value only comes from this feature being available by default on all machines, so it becomes a question of "does this add enough value to be worth the pain?" For education purposes, it certainly does. My gut feel is that when this sort of change comes with an operating system upgrade (not just an update), it'll be okay, and if it's opt-in for earlier versions then people won't be too surprised. But, alas, I've been finding myself with not enough support around the company to get it through, and not enough time to do all the politicking and engineering work myself. I started a launcher rewrite at https://github.com/zooba/PyLauncher if anyone is interested in looking (it's very C++, as opposed to C). Can't promise that it'd remain open-source or accept contributions, but I'd certainly try. Cheers, Steve
On 16 Mar 2016 18:44, "Steve Dower" <steve.dower@python.org> wrote:
been long-term compatibility. Basically, we're in the same category as LTS RHEL: whatever ships now *will still be 100% compatible with what we are shipping in ten years time* (yes, that's an aspiration more than a guarantee, but it certainly rules out 3.n->3.(n+1) upgrades).
As a result, if Python did ship in Windows, I'd be trying really hard to
make it an internal implementation detail to discourage people from ever relying on it. As Nick Coghlan said when I last chatted with him about this, "please, please, learn from our mistakes" :) I can understand that. The OSX system Python is like that. You're not supposed to mess with it and when you want to do some programming every guide suggests to install a newer non-system Python. I often see reports of people getting into trouble after removing the system Python because they wanted a newer version for some reason. However I do really like the fact that there is *some* Python installed and Windows is the only OS where this is not the case. As long as some Python is installed I can bundle a bunch of Python code in a zip file and I've got a portable program. On Windows it's only portable if you ask someone to install Python first which is often a deal-breaker (hence py2exe). scripts will run with the correct version on new machines.
The install step may be painful the first time, but since Python 3.5+
does not require admin privileges, it should be quick and easy for most people. I don't see us going out of our way to update legacy versions to do this - they'll continue to need admin privileges So this Python.exe is a launcher that is bundled with Windows which solves your concerns about PATH manipulation and then when Python is actually installed it hooks into this launcher? that when this sort of change comes with an operating system upgrade (not just an update), it'll be okay, and if it's opt-in for earlier versions then people won't be too surprised.
But, alas, I've been finding myself with not enough support around the
company to get it through, and not enough time to do all the politicking and engineering work myself. I started a launcher rewrite at https://github.com/zooba/PyLauncher if anyone is interested in looking (it's very C++, as opposed to C). Can't promise that it'd remain open-source or accept contributions, but I'd certainly try. To what extent can the same benefits be achieved by bundling the same launcher in the Python installer? Is it just that it would require elevated privileges? I'm not sure that that would be a significant problem for e.g. my students. They'd just have to type in their passwords (on their own laptops) right? -- Oscar
On 17 March 2016 at 08:13, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
"This is for operating system use, do not touch unless you're developing an operating system component" is the direction we're wanting to take the system Python installation on Fedora by moving it out to a dedicated "system-python" executable: https://fedoraproject.org/wiki/Changes/System_Python Once we can get the OS itself to a point of not caring what gets run when you invoke "/usr/bin/python" or "/usr/bin/python3", then we gain a lot more flexibility in how we handle the default symlinks (e.g. replacing them with something like Geoffrey Thomas's Python-launcher-for-POSIX-systems [1], or just letting machine admins configure them via existing alternatives management systems) Cheers, Nick. [1] https://ldpreload.com/blog/usr-bin-python-23 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mar 16, 2016, at 11:15, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
I love Steve's idea, but I think you're overselling it.
Then I guess all the major OSes would ship with Python making simple Python scripts portable
Only if they're dual-version (2.7/3.x), and don't depend on anything from PyPI, and can ignore Windows 8 and earlier. That rules out novice education, many utility scripts that would be twice as complicated if they have to be dual-version or can't use requests or whatever, etc.
and solving a lot of the problems that pyinstaller/py2exe try to solve.
I don't think it will. Even ignoring 3.x, py2app isn't any simpler since Apple started shipping 2.7 preinstalled. In fact, if anything, it's gotten more complicated. The hard part of py2exe isn't wrapping Python.exe and python36.zip up together with your site-packages.zip, it's working out what has to go in that site-packages.zip, and what extra DLLs are needed because they're linked by a .pyd or explicitly opened via ctypes/cffi, and so on. So, even if you could rely on python and its stdlib already being present, py2exe would still have to do all the hard stuff. But you really can't even rely on that. For example, you may need a specific version (obviously 3.6+ is good enough for 2016, but will that still be true by the time "requires Windows 10" is a reasonable thing for apps to specify?); you'll almost certainly explicitly require either 32-bit or 64-bit; etc.
On 16Mar2016 1115, Oscar Benjamin wrote:
So my main concern about getting Python shipping with Windows has always been long-term compatibility. Basically, we're in the same category as LTS RHEL: whatever ships now *will still be 100% compatible with what we are shipping in ten years time* (yes, that's an aspiration more than a guarantee, but it certainly rules out 3.n->3.(n+1) upgrades). As a result, if Python did ship in Windows, I'd be trying really hard to make it an internal implementation detail to discourage people from ever relying on it. As Nick Coghlan said when I last chatted with him about this, "please, please, learn from our mistakes" :) So the idea that I was working on was effectively the py.exe launcher, but taking over the global "python" name (and probably "python3"/"python2"), and with the addition of useful error messages (i.e. with URLs or extra tools) for when you try and run "python" without having installed it. And also add proper support for configuring defaults and active virtual environments (which are both in the current py.exe launcher, but seem to not be well known). Shebang support would stick around and be encouraged, along with specifying Python language versions such that scripts will run with the correct version on new machines. The install step may be painful the first time, but since Python 3.5+ does not require admin privileges, it should be quick and easy for most people. I don't see us going out of our way to update legacy versions to do this - they'll continue to need admin rights. This would obviously be a big and unexpected change for users, but it seems to be the most viable way of making Python universally available without locking into a specific version for 10+ years or essentially forking a "Microsoft Python" that ends up being very different from CPython releases. And the value only comes from this feature being available by default on all machines, so it becomes a question of "does this add enough value to be worth the pain?" For education purposes, it certainly does. My gut feel is that when this sort of change comes with an operating system upgrade (not just an update), it'll be okay, and if it's opt-in for earlier versions then people won't be too surprised. But, alas, I've been finding myself with not enough support around the company to get it through, and not enough time to do all the politicking and engineering work myself. I started a launcher rewrite at https://github.com/zooba/PyLauncher if anyone is interested in looking (it's very C++, as opposed to C). Can't promise that it'd remain open-source or accept contributions, but I'd certainly try. Cheers, Steve
On 16 Mar 2016 18:44, "Steve Dower" <steve.dower@python.org> wrote:
been long-term compatibility. Basically, we're in the same category as LTS RHEL: whatever ships now *will still be 100% compatible with what we are shipping in ten years time* (yes, that's an aspiration more than a guarantee, but it certainly rules out 3.n->3.(n+1) upgrades).
As a result, if Python did ship in Windows, I'd be trying really hard to
make it an internal implementation detail to discourage people from ever relying on it. As Nick Coghlan said when I last chatted with him about this, "please, please, learn from our mistakes" :) I can understand that. The OSX system Python is like that. You're not supposed to mess with it and when you want to do some programming every guide suggests to install a newer non-system Python. I often see reports of people getting into trouble after removing the system Python because they wanted a newer version for some reason. However I do really like the fact that there is *some* Python installed and Windows is the only OS where this is not the case. As long as some Python is installed I can bundle a bunch of Python code in a zip file and I've got a portable program. On Windows it's only portable if you ask someone to install Python first which is often a deal-breaker (hence py2exe). scripts will run with the correct version on new machines.
The install step may be painful the first time, but since Python 3.5+
does not require admin privileges, it should be quick and easy for most people. I don't see us going out of our way to update legacy versions to do this - they'll continue to need admin privileges So this Python.exe is a launcher that is bundled with Windows which solves your concerns about PATH manipulation and then when Python is actually installed it hooks into this launcher? that when this sort of change comes with an operating system upgrade (not just an update), it'll be okay, and if it's opt-in for earlier versions then people won't be too surprised.
But, alas, I've been finding myself with not enough support around the
company to get it through, and not enough time to do all the politicking and engineering work myself. I started a launcher rewrite at https://github.com/zooba/PyLauncher if anyone is interested in looking (it's very C++, as opposed to C). Can't promise that it'd remain open-source or accept contributions, but I'd certainly try. To what extent can the same benefits be achieved by bundling the same launcher in the Python installer? Is it just that it would require elevated privileges? I'm not sure that that would be a significant problem for e.g. my students. They'd just have to type in their passwords (on their own laptops) right? -- Oscar
On 17 March 2016 at 08:13, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
"This is for operating system use, do not touch unless you're developing an operating system component" is the direction we're wanting to take the system Python installation on Fedora by moving it out to a dedicated "system-python" executable: https://fedoraproject.org/wiki/Changes/System_Python Once we can get the OS itself to a point of not caring what gets run when you invoke "/usr/bin/python" or "/usr/bin/python3", then we gain a lot more flexibility in how we handle the default symlinks (e.g. replacing them with something like Geoffrey Thomas's Python-launcher-for-POSIX-systems [1], or just letting machine admins configure them via existing alternatives management systems) Cheers, Nick. [1] https://ldpreload.com/blog/usr-bin-python-23 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mar 16, 2016, at 11:15, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
I love Steve's idea, but I think you're overselling it.
Then I guess all the major OSes would ship with Python making simple Python scripts portable
Only if they're dual-version (2.7/3.x), and don't depend on anything from PyPI, and can ignore Windows 8 and earlier. That rules out novice education, many utility scripts that would be twice as complicated if they have to be dual-version or can't use requests or whatever, etc.
and solving a lot of the problems that pyinstaller/py2exe try to solve.
I don't think it will. Even ignoring 3.x, py2app isn't any simpler since Apple started shipping 2.7 preinstalled. In fact, if anything, it's gotten more complicated. The hard part of py2exe isn't wrapping Python.exe and python36.zip up together with your site-packages.zip, it's working out what has to go in that site-packages.zip, and what extra DLLs are needed because they're linked by a .pyd or explicitly opened via ctypes/cffi, and so on. So, even if you could rely on python and its stdlib already being present, py2exe would still have to do all the hard stuff. But you really can't even rely on that. For example, you may need a specific version (obviously 3.6+ is good enough for 2016, but will that still be true by the time "requires Windows 10" is a reasonable thing for apps to specify?); you'll almost certainly explicitly require either 32-bit or 64-bit; etc.
participants (4)
-
Andrew Barnert -
Nick Coghlan -
Oscar Benjamin -
Steve Dower