Hi all, There is a recurring problem in my company where we use python in various places (python3). We do cross platform development windows/linux and our python scripts need to run everywhere. Some scripts are launched manually in a terminal. Others are launched via windows' gui interface. Others are launched through our build process (cmake based, but also manual Makefile) And others are launched via bash scripts. And possible several other scenario I've forgot. On windows, most users use Cygwin to do their terminal based business (`git`, `cmake`, ...). The issue is: There is no reliable way to launch a python script. The command: python myscript.py launches python3 on windows and python2 on 99% of the unix market. The command python3 myscript.py does not run on windows with the latest python distribution I've played with (sorry if it has been fixed recently, this whole mail becomes pointless). Human can learn which command to run, it's ok. But for all other invocations context, this becomes very annoying. Surprisingly, `cmake` is the more friendly, since `FindPython` will returns a python3 first. At the moment, we have scripts that run under version 2 when run by a linux user and version 3 on windows. This works by pure luck. If the standard python distro would just provide a simple `python3` binary/alias, then all the stars would align perfectly. the basic shebang #! /usr/bin/env python3 would work everywhere by default, without requiring any tweaking (install a python3 alias on windows, or ask linux users to change the default `python` symlink) I'm sure, I'm far from being the first user complaining about that. Sorry if the request has been been made numerous time before. What it the status on this point ? Thanks a lot. Fred
Hi Fred, If windows users associate .py with the py.exe launcher, (and .pyw with the pyw.exe launcher), then it will default to python 3 (highest version installed, 64 bit if available), and will honour a `#! python3` shebang, (with a number of formats accepted). It should also be reasonably easy to teach the users to type: py scriptname rather than python or python3 scriptname (less to type rather than more). The link for details is https://docs.python.org/3/using/windows.html#python-launcher-for-windows and there are details on installation further up the page. Hope that this answers your problem. Steve Barnes -----Original Message----- From: Frédéric De Jaeger <fdejaeger@novaquark.com> Sent: 23 March 2020 18:00 To: python-ideas@python.org Subject: [Python-ideas] About python3 on windows Hi all, There is a recurring problem in my company where we use python in various places (python3). We do cross platform development windows/linux and our python scripts need to run everywhere. Some scripts are launched manually in a terminal. Others are launched via windows' gui interface. Others are launched through our build process (cmake based, but also manual Makefile) And others are launched via bash scripts. And possible several other scenario I've forgot. On windows, most users use Cygwin to do their terminal based business (`git`, `cmake`, ...). The issue is: There is no reliable way to launch a python script. The command: python myscript.py launches python3 on windows and python2 on 99% of the unix market. The command python3 myscript.py does not run on windows with the latest python distribution I've played with (sorry if it has been fixed recently, this whole mail becomes pointless). Human can learn which command to run, it's ok. But for all other invocations context, this becomes very annoying. Surprisingly, `cmake` is the more friendly, since `FindPython` will returns a python3 first. At the moment, we have scripts that run under version 2 when run by a linux user and version 3 on windows. This works by pure luck. If the standard python distro would just provide a simple `python3` binary/alias, then all the stars would align perfectly. the basic shebang #! /usr/bin/env python3 would work everywhere by default, without requiring any tweaking (install a python3 alias on windows, or ask linux users to change the default `python` symlink) I'm sure, I'm far from being the first user complaining about that. Sorry if the request has been been made numerous time before. What it the status on this point ? Thanks a lot. Fred _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PTYLAO... Code of Conduct: http://python.org/psf/codeofconduct/
On Mar 23, 2020, at 11:16, Frédéric De Jaeger <fdejaeger@novaquark.com> wrote:
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
While that’s true for Mac 10.14, Ubuntu 18.04 LTS, etc., I think almost everyone is deprecating Python 2 in their current releases, so that’s not really true anymore. And, while there’s nothing wrong with running 2-year-old OS versions, I’m not sure it’s worth making any changes to Python to help such environments, because it won’t help many people until after it’s too late to matter anyway. (If Python 3.10 does something different, and it becomes the default in Ubuntu 22.04 LTS, your company probably won’t see any benefit until at least 2023…) It’s worth reading PEP 394 (the Python command on Unix-like systems) and PEP 397 (the Python launcher for Windows) for background. But I think the assumption is that you create executable scripts with #! /usr/bin/env python3, and then your other scripts just execute the scripts directly, which will go through the default shell on *nix (which will process the shbang line and run whatever is called python3 on the path) and through py.exe on Windows (which has special code to understand common shbang lines and do the right thing). But there are other options to make things even easier. If you use virtual environments, the python command inside a venv always runs the Python version for that venv. If you create things to be installed rather than run in-place, setuptools entry points automatically get turned into scripts set up in a way that’s appropriate for the local system. If you have Windows users who aren’t Python-savvy at all, it may even be worth using one of the binary-program makers like PyInstaller so they can just run an installer off your intranet and get something that looks like a normal .exe file on their PATH that doesn’t depend on any Python installation. One more thing:
On windows, most users use Cygwin to do their terminal based business (`git`, `cmake`, ...).
It’s been a while since I worked in a Cygwin-heavy environment, but if you’re writing shell scripts to run in Cygwin that use Python scripts, don’t you still need a Cygwin Python rather than a native Windows ones, so things like pathnames work properly? Or is that not a problem anymore? And if you do, doesn’t the Cygwin Python 3 package install something named python3 that’s on the (Cygwin) PATH, same as on your *nix systems?
On Mon, Mar 23, 2020 at 05:59:41PM -0000, Fr??d??ric De Jaeger <fdejaeger@novaquark.com> wrote:
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
Create and activate a virtual environment (``virtualenv`` or ``python -m venv``) and always use ``python myscript.py``. Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Mon, Mar 23, 2020 at 08:09:57PM +0100, Oleg Broytman wrote:
On Mon, Mar 23, 2020 at 05:59:41PM -0000, Fr??d??ric De Jaeger <fdejaeger@novaquark.com> wrote:
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
Create and activate a virtual environment (``virtualenv`` or ``python -m venv``) and always use ``python myscript.py``.
Won't that create a virtual environment using Python3 on Windows and using Python2 most other places, which is exactly the problem Fred is having? Doesn't using a virtual environment require the caller to explicitly activate it, otherwise they will still get the system (global) Python? If Fred successfully creates a virtualenv using the correct version of Python, how does that help him when he distributes his script across his organisation, and to his users? Some of them may not have access to Fred's virtualenv. These are not rhetorical questions. I'm not a heavy virtualenv user and I may not understand it fully. -- Steven
On Tue, Mar 24, 2020 at 10:22:28AM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Mar 23, 2020 at 08:09:57PM +0100, Oleg Broytman wrote:
On Mon, Mar 23, 2020 at 05:59:41PM -0000, Fr??d??ric De Jaeger <fdejaeger@novaquark.com> wrote:
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
Create and activate a virtual environment (``virtualenv`` or ``python -m venv``) and always use ``python myscript.py``.
Won't that create a virtual environment using Python3 on Windows and using Python2 most other places, which is exactly the problem Fred is having?
Depends on how literally one reads ``python -m venv``. Just for example: I run a lot of tests for my libraries locally under all possible Pythons so I have all versions -- 2.7 and 3.4+ up to 3.8 (soon to add 3.9) -- so I create all possible venvs; I run Windows inside VirtualBox emulator where I have even more Pythons -- 32-bit and 64-bit. When I need a particular version I create, activate and populate a specific venv.
Doesn't using a virtual environment require the caller to explicitly activate it, otherwise they will still get the system (global) Python?
Yes. I don't think it's a major problem. Activating a venv once (for a terminal) is surely simpler than remembering the difference between ``python`` and ``python3``, ``pip`` and ``pip3``, ``pip2.7``, ``pip3.5`` and ``pip3.6``.
If Fred successfully creates a virtualenv using the correct version of Python, how does that help him when he distributes his script across his organisation, and to his users? Some of them may not have access to Fred's virtualenv.
Python virtualenv is a development tool but not a distribution or a deployment tool. To distribute a script one is recommended to build a wheel and allow ``pip`` to configure the script to use a proper Python version. Even better (but harder) distribution/deployment tools are freezers -- cx_Freeze/PyInstaller/pyapp/pyexe. They bundle the required Python and a subset of the standard library with the script. Even better (but even more harder) are OS-specific installers -- RPM, deb, w32 installers.
These are not rhetorical questions. I'm not a heavy virtualenv user and I may not understand it fully. -- Steven
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Tue, Mar 24, 2020 at 12:45:42AM +0100, Oleg Broytman wrote:
Won't that create a virtual environment using Python3 on Windows and using Python2 most other places, which is exactly the problem Fred is having?
Depends on how literally one reads ``python -m venv``.
I read it as what you wrote, should I have read it as something else? Fred is explicitly asking about the problem with having to sometimes use python and sometimes python3, and your answer is to tell him to sometimes use python and sometimes use python3?
Python virtualenv is a development tool but not a distribution or a deployment tool.
Fred is discussing the problems he is having with distribution and deployment, not development. His issue is that "python" means different things on different machines and different users. -- Steven
On Tue, Mar 24, 2020 at 11:30:38AM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Mar 24, 2020 at 12:45:42AM +0100, Oleg Broytman wrote:
Won't that create a virtual environment using Python3 on Windows and using Python2 most other places, which is exactly the problem Fred is having?
Depends on how literally one reads ``python -m venv``.
I read it as what you wrote, should I have read it as something else?
As a template.
Fred is explicitly asking about the problem with having to sometimes use python and sometimes python3, and your answer is to tell him to sometimes use python and sometimes use python3?
Once for every venv created, not once for every script being run.
Python virtualenv is a development tool but not a distribution or a deployment tool.
Fred is discussing the problems he is having with distribution and deployment, not development.
IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users.
His issue is that "python" means different things on different machines and different users.
This part is not solvable. Python **means** different things on different machines and different users.
-- Steven
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 24/03/2020 01:13, Oleg Broytman wrote:
On Tue, Mar 24, 2020 at 11:30:38AM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
Fred is explicitly asking about the problem with having to sometimes use python and sometimes python3, and your answer is to tell him to sometimes use python and sometimes use python3?
Once for every venv created, not once for every script being run.
I'm afraid the terseness of your answer didn't make it at all clear how creating venvs would solve Fred's problems. It still isn't obvious to me!
Fred is discussing the problems he is having with distribution and deployment, not development.
IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users.
For most circumstances, that is not a practical answer. Creating wheels or frozen binaries are subjects that most Python programmers know little about and care less about. Expecting someone to learn how to wield the packaging system just to do internal distribution is unrealistic. Also, where is it said that distributing wheels or frozen binaries is best practice? I wasn't aware of any such statement, and indeed have seen frozen binaries discouraged in the past. -- Rhodri James *-* Kynesim Ltd
On Tue, Mar 24, 2020 at 09:40:07AM +0000, Rhodri James <rhodri@kynesim.co.uk> wrote:
I'm afraid the terseness of your answer didn't make it at all clear how creating venvs would solve Fred's problems. It still isn't obvious to me!
One doesn't create virtual environments every day; once a year may be. And there are projects that help managing environments if there are many (virtualenvwrapper and virtualenvwrapper-win). One doesn't activate venvs to run every script; once a day usually, or once for every new terminal. And there're projects that help running scripts in venvs automatically (pipsi and pipx). Once a venv is activated there is no need to remember different commands -- it's always ``python`` and ``pip``. In all operating systems. It's what the OP wants, right?
-- Rhodri James *-* Kynesim Ltd
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Tue, 24 Mar 2020 at 09:41, Rhodri James <rhodri@kynesim.co.uk> wrote:
On 24/03/2020 01:13, Oleg Broytman wrote:
IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users.
For most circumstances, that is not a practical answer. Creating wheels or frozen binaries are subjects that most Python programmers know little about and care less about. Expecting someone to learn how to wield the packaging system just to do internal distribution is unrealistic.
Agreed (and I speak as a packaging specialist!) We shouldn't be promoting something as heavyweight as building wheels or freezing a whole Python application just to share scripts between colleagues. I think the advice to use shebang lines in scripts, and run those scripts directly on Unix, and via the py launcher (or using the .py filetype association with the launcher) is about right. It's not 100% seamless, and it does need some level of configuration and setup on the machines that are expected to run the scripts - and you need to manually manage any package dependencies for yourself - but I think it's sufficient. On Tue, 24 Mar 2020 at 11:00, Frédéric De Jaeger <fdejaeger@novaquark.com> wrote:
One of our constraint is that we use Cygwin's bash and now, every user relies on the shebang.
Cygwin is an additional level of complexity. It attempts to provide a "Unix-like" environment on Windows - and it does a very good job of that! But it *isn't* Unix, and so there are differences. Expecting two completely different operating systems to behave identically is, IMO, a bit optimistic. You really need to be able to assume a base level of knowledge from your users (or you have to go down the route of bundling Python scripts into standalone "no knowledge required" applications). To me, that base level of knowledge would be "the user knows how to run a Python script". But I understand that this is basically the point of your question. Conversely, if I handed your users a Ruby script (or a Perl script, or a Javascript program) - would they be able to run them with no additional knowledge? I don't think the problem you have here is unique to Python, it's equally applicable to any language with a runtime that needs to be installed and invoked.
The problem reduce to this. Assuming you are in a bash window (whether on cygwin or ubuntu 18, or mac os) and you do this:
> ./myScript.py
How do you write the shebang so it runs reliably python3 with the minimal amount of energy spent configuring the system.
If you're in a bash window on Cygwin, did you install Cygwin Python or Windows native Python? The answer is probably different depending on which scenario applies. And integrating Cygwin bash with native Windows Python is always going to be a little clumsy, as you're dealing with the differences with two environments that work very differently. Paul
On Mon, Mar 23, 2020 at 6:19 PM Oleg Broytman <phd@phdru.name> wrote:
IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users.
This is a good point, though I’m not sure the best solution. Frozen Binaries (py2exe, PyInstaller) are a good solution if you have one or two applications. But if you have a a whole bunch of small scripts, then each one would have a full copy of Python -- not ideal. So what about wheels? That may be a good way to go. wheels are a complete package bundled up that can be installed into the Python environment. And that can include scripts. So you should be able to install a wheel into the correct Python, and then have access to scripts. The trick is that the user needs to know how to install that wheel, and they need to install it into the "right" python. `pip install the_wheel` is only going to work if its the right pip. and `python -m pip install the_wheel` has all the same problems that the OP's concerned about here. However, that is a one-time issue -- you get your users to install the wheel correctly, and then they have access to the script without anything special from there. And you could probably make an installer that would install it in the right place automatically (I know that back in the day, we were looking at associating an app with wheels on the Mac, so they could be point and clicked on and get installed -- one could do that for Windows, yes? But back to the OP's issue: Python can be considered a "scripting" language, and it IS useful when used that way, for smaller utilities that don't have a lot of dependencies, etc. And it is nice to be able to just drop a script somewhere and run it. And that works well on *nix systems -- just set the #! line and away you go. But in a cross platform environment, there are two key problems: 1) Windows works differently than *nix, but at a fundamental level (no #! line, different handling of PATH) and on a conventional level -- there simply isn't the same isn't the same culture of command line use. Given (1) Python had to do something differently on Windows than *nix (and the Mac, though that's converged more now), which brings us to problem (2) 2) The Python community came up with solutions for each platform that made sense for that platform: the conventions for *nix, and the py.exe launcher for Windows. But there was little effort made to make the user experience the SAME on all platforms. Personally, I think that's a shame, as Brett pointed out, there's no reason you couldn't have a "py" launcher on *nix, and there's no reason you couldn't have a "python3" alias on Windows installs. Whether that would be a good idea is debatable, the platforms are different, the user base is different: could *nix users use a py launcher anyway? Would Windows users want to put "python3" on their PATH? (or know how to?). There was a pretty involved discussion about this about a year ago (?) -- which I think led to Brett deciding to give a py launcher for *nix a chance. I *think* it was on python-dev. But interested parties should go look for it. There is also the problem that as time has gone no, PEP 394 ( https://www.python.org/dev/peps/pep-0394/) was created in 2011 -- the python world has changed: there are more systems with only Python3, and there are various virtual environment systems, like conda, that manage the entire environment, so there's a whole new way to manage which Python version to use. (though conda, at least, does provide a "python3" command -- I wonder if it does on Windows?) So I'm not sure the PEP 394. But back to the OP's problem: what to do now? My suggestions for options: 1) Have a "standard" python install for your users, and use wheels to distribute your scripts. That actually has the advantage that you can put a library in there, and multiple scripts, and all sorts of nifty stuff. It might be nicer to bundle up related scripts anyway. - wheels can be tagged with Python version, so it can't be installed into the wrong one. 2) Provide clear instructions for users: and they WILL be different on Windows and *nix. - I got the impression that one problem was finger memory for users of multiple OSs -- I have this problem, too. In that case, you could also make a copy of py.exe. and name it python3.exe -- problem solved :-) (now that i think about it, is there any reason cPython couldn't' install a set of aliases (or copies, or links, or) to the py launcher called "python" and "python3" ? 3) In scripts that can only be run in Python3, have a little check at the top that makes sure it's being run in Python3, and give a meaningful message if it's not: if sys.version_info.major != 3: print("You are not running the correct version of Python: please install Python3," "and run this script with:\n" " ) That leaves open the Python-ideas part of this: should the standard Python installers do anything different than they do? -CHB
His issue is that "python" means different things on different machines and different users.
This part is not solvable. Python **means** different things on different machines and different users.
-- Steven
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VMZBOM... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Wed, Mar 25, 2020 at 7:29 AM Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, Mar 23, 2020 at 6:19 PM Oleg Broytman <phd@phdru.name> wrote:
IMO the issue is in not following the best practices. Distribute wheels or freezed binaries, not just drop scripts unto users.
This is a good point, though I’m not sure the best solution. Frozen Binaries (py2exe, PyInstaller) are a good solution if you have one or two applications. But if you have a a whole bunch of small scripts, then each one would have a full copy of Python -- not ideal.
Extremely unideal, since then it's the app publisher's responsibility to keep on top of Python version updates and rebundle.
2) Provide clear instructions for users: and they WILL be different on Windows and *nix. - I got the impression that one problem was finger memory for users of multiple OSs -- I have this problem, too. In that case, you could also make a copy of py.exe. and name it python3.exe -- problem solved :-) (now that i think about it, is there any reason cPython couldn't' install a set of aliases (or copies, or links, or) to the py launcher called "python" and "python3" ?
Aliasing py as python and python3 would be great, as long as that doesn't introduce bizarrenesses of any sort. That would also work for scripts (makefiles, 'npm run blah', etc), which AIUI was the OP's main issue.
3) In scripts that can only be run in Python3, have a little check at the top that makes sure it's being run in Python3, and give a meaningful message if it's not:
if sys.version_info.major != 3: print("You are not running the correct version of Python: please install Python3," "and run this script with:\n" " )
That leaves open the Python-ideas part of this: should the standard Python installers do anything different than they do?
What I would really like would be for Windows to ship with a "python.exe" and a "python3.exe" that inform the user that the script requested requires Python, please install it from the app store. And if it IS installed, just exec straight into py. But I'm sure this would cause other issues somewhere. ChrisA
On 2020-03-23 10:59, Frédéric De Jaeger wrote:
Hi all,
There is a recurring problem
Yep, that's a problem. I've built up a habit on Ubuntu where I type python3 a number of times a day, honed over several years. So far so good. Recently I've had to use a Windows VM for some stuff at work, where I installed Python 3 as well. Every time I type python3 at the command-line (instead of python) to use the repl, it tries to load the Microsoft App Store! I realize why that was done, to help out newbies, but it is not what I want at all. Not the end of the world, but some consistency would be nice. -Mike
On Mon, Mar 23, 2020 at 3:47 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-03-23 10:59, Frédéric De Jaeger wrote:
Hi all,
There is a recurring problem
Yep, that's a problem. I've built up a habit on Ubuntu where I type python3 a number of times a day, honed over several years. So far so good.
Also note that Python doesn't control the OS vendors and this is very much a vendor decision. We tried to provide guidance, but that doesn't mean we are listened to. :)
Recently I've had to use a Windows VM for some stuff at work, where I installed Python 3 as well. Every time I type python3 at the command-line (instead of python) to use the repl, it tries to load the Microsoft App Store!
There is an option to install Python to PATH on Windows if you check the appropriate box during installation, but that's not really the way Windows apps typically work.
I realize why that was done, to help out newbies, but it is not what I want at all. Not the end of the world, but some consistency would be nice.
As I said, you can install Python to PATH on Windows if you choose. I'm also slowly working on a Python Launcher for UNIX so the other option some day might be `py` no matter what OS you're on. -Brett
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUEC... Code of Conduct: http://python.org/psf/codeofconduct/
Brett Cannon wrote:
There is an option to install Python to PATH on Windows if you check the appropriate box during installation, but that's not really the way Windows apps typically work.
In this case of the OP, if they're mass installing Python on company Windows devices, they might want to consider using the PrependPath option (which adds Python to PATH from the command line). I.E. python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1 (IIRC, the above installation should allow usage of "python3" on Windows for all users on the device) On Mon, Mar 23, 2020 at 7:52 PM Brett Cannon <brett@python.org> wrote:
On Mon, Mar 23, 2020 at 3:47 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-03-23 10:59, Frédéric De Jaeger wrote:
Hi all,
There is a recurring problem
Yep, that's a problem. I've built up a habit on Ubuntu where I type python3 a number of times a day, honed over several years. So far so good.
Also note that Python doesn't control the OS vendors and this is very much a vendor decision. We tried to provide guidance, but that doesn't mean we are listened to. :)
Recently I've had to use a Windows VM for some stuff at work, where I installed Python 3 as well. Every time I type python3 at the command-line (instead of python) to use the repl, it tries to load the Microsoft App Store!
There is an option to install Python to PATH on Windows if you check the appropriate box during installation, but that's not really the way Windows apps typically work.
I realize why that was done, to help out newbies, but it is not what I want at all. Not the end of the world, but some consistency would be nice.
As I said, you can install Python to PATH on Windows if you choose.
I'm also slowly working on a Python Launcher for UNIX so the other option some day might be `py` no matter what OS you're on.
-Brett
-Mike _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUEC... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NZ3J3Y... Code of Conduct: http://python.org/psf/codeofconduct/
Windows devices, they might want to consider using the PrependPath option (which adds Python to PATH from the command line). I.E. python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1 (IIRC, the above installation should allow usage of "python3" on Windows for all users on the device)
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ?
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ?
I believe it only applies to the traditional installer from python.org. You will also have to verify it, as it has been a decent while since I've had to install Python on Windows. On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger <fdejaeger@novaquark.com> wrote:
Windows devices, they might want to consider using the PrependPath option (which adds Python to PATH from the command line). I.E. python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1 (IIRC, the above installation should allow usage of "python3" on Windows for all users on the device)
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4Y... Code of Conduct: http://python.org/psf/codeofconduct/
https://docs.python.org/3.8/using/windows.html#installing-without-ui gives details of all of the options. The Microsoft Store version does not offer any options full stop! From: Kyle Stanley <aeros167@gmail.com> Sent: 24 March 2020 18:10 To: Frédéric De Jaeger <fdejaeger@novaquark.com> Cc: Python-ideas < > Subject: [Python-ideas] Re: About python3 on windows
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ?
I believe it only applies to the traditional installer from python.org<http://python.org>. You will also have to verify it, as it has been a decent while since I've had to install Python on Windows. On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger <fdejaeger@novaquark.com<mailto:fdejaeger@novaquark.com>> wrote:
Windows devices, they might want to consider using the PrependPath option (which adds Python to PATH from the command line). I.E. python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1 (IIRC, the above installation should allow usage of "python3" on Windows for all users on the device)
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org<mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org<mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4Y... Code of Conduct: http://python.org/psf/codeofconduct/
The Microsoft Store version does not offer any options full stop!
Good to know, thanks for clarifying. I haven't personally installed it from the Microsoft app store, but it was my assumption that it did not allow for custom installation options. On Tue, Mar 24, 2020 at 3:18 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:
https://docs.python.org/3.8/using/windows.html#installing-without-ui gives details of all of the options. The Microsoft Store version does not offer any options full stop!
*From:* Kyle Stanley <aeros167@gmail.com> *Sent:* 24 March 2020 18:10 *To:* Frédéric De Jaeger <fdejaeger@novaquark.com> *Cc:* Python-ideas < > *Subject:* [Python-ideas] Re: About python3 on windows
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ?
I believe it only applies to the traditional installer from python.org. You will also have to verify it, as it has been a decent while since I've had to install Python on Windows.
On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger < fdejaeger@novaquark.com> wrote:
Windows devices, they might want to consider using the PrependPath option (which adds Python to PATH from the command line). I.E. python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1 (IIRC, the above installation should allow usage of "python3" on Windows for all users on the device)
That would be nice. Does it apply to the _windows store version_, the _traditional installer_, both ? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4Y... Code of Conduct: http://python.org/psf/codeofconduct/
On 2020-03-23 16:49, Brett Cannon wrote:
Recently I've had to use a Windows VM for some stuff at work, where I installed Python 3 as well. Every time I type python3 at the command-line (instead of python) to use the repl, it tries to load the Microsoft App Store!
There is an option to install Python to PATH on Windows if you check the appropriate box during installation, but that's not really the way Windows apps typically work.
I realize why that was done, to help out newbies, but it is not what I want at all. Not the end of the world, but some consistency would be nice.
As I said, you can install Python to PATH on Windows if you choose.
Was pretty sure I did that and just checked. Here is the result, backwards from Ubuntu, if you'd like to run Python3: Microsoft Windows [Version 10.0.18363.720] (c) 2019 Microsoft Corporation. All rights reserved. C:\Users\User>path PATH=C:\Python38\Scripts\;C:\Python38\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\ System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Yori;C:\Program Files\Yori;C:\Users\User\AppData\Local\Microsoft\WindowsApps;;C:\Users\User \AppData\Local\Programs\Microsoft VS Code\bin C:\Users\User>python Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z C:\Users\User>python3 (App store loads!!) C:\Users\User>cd \Python38 C:\Python38>dir Volume in drive C has no label. Volume Serial Number is 4A31-C9FC Directory of C:\Python38 2019-12-07 05:40 PM <DIR> . 2019-12-07 05:40 PM <DIR> .. 2019-12-07 05:40 PM <DIR> DLLs 2019-12-07 05:40 PM <DIR> Doc 2019-12-07 05:39 PM <DIR> include 2019-12-07 05:40 PM <DIR> Lib 2019-12-07 05:39 PM <DIR> libs 2019-10-14 08:43 PM 31,322 LICENSE.txt 2019-10-14 08:44 PM 866,080 NEWS.txt 2019-10-14 08:43 PM 99,912 python.exe 2019-10-14 08:43 PM 58,952 python3.dll 2019-10-14 08:43 PM 4,183,112 python38.dll 2019-10-14 08:43 PM 98,376 pythonw.exe 2020-03-17 03:01 PM <DIR> Scripts 2019-12-07 05:40 PM <DIR> Tools 2019-10-14 08:43 PM 89,752 vcruntime140.dll 7 File(s) 5,427,506 bytes 9 Dir(s) 108,736,249,856 bytes free Note there is no python3.exe binary. -Mike
On 3/24/20, Mike Miller <python-ideas@mgmiller.net> wrote:
C:\Users\User>python3 (App store loads!!)
If installed, the app distribution has an appexec link for "python3.exe" that actually works.
C:\Python38>dir Volume in drive C has no label. [snip] Note there is no python3.exe binary.
You can manually copy or symlink python.exe to python3.exe in the installation directory and venv "Scripts" directories. However, it will only be used on the command line, and other contexts that search PATH. Currently the launcher will not use it with a virtual "env" shebang. The launcher will search PATH for "python", but not "python3".
On 2020-03-24 11:58, Eryk Sun wrote:
On 3/24/20, Mike Miller <python-ideas@mgmiller.net> wrote:
C:\Users\User>python3 (App store loads!!)
If installed, the app distribution has an appexec link for "python3.exe" that actually works.
C:\Python38>dir Volume in drive C has no label. [snip] Note there is no python3.exe binary.
You can manually copy or symlink python.exe to python3.exe in the installation directory and venv "Scripts" directories. However, it will only be used on the command line, and other contexts that search PATH. Currently the launcher will not use it with a virtual "env" shebang. The launcher will search PATH for "python", but not "python3".
Thanks. Sure, there are many ways to fix this manually, or work around it. Would be great if it was consolidated, with one command "to rule them all."
Of course if, rather than creating symlinks, you create a batch file called python3.bat and containing the line: @py -3 %* Then save it to somewhere on your path, e.g. the python scripts directory, then issuing, from the command line or another batch file the command python3 should just work (as long as the chosen location is earlier in the path than %appdata%\..\Local\Microsoft\WindowsApps\ which is where the python3.exe app store launcher lives). As the py launcher works just find in MinGW you can either do the same with a bash script or an alias and the Windows System For Linux allows you to install python3 as well as python (on my system the latest versions are 3.5.1-3 & 2.7.12-1). It is also worth mentioning that python (and the py launcher) both accept windows paths (\ separated) and *nix paths (/ separated) from the command line and that from within scripts the *nix path separator is to be preferred as it will not require either being in a r-string or escaped i.e. you can use glob.glob(r"C:\Users\Gadget\*.docx") or glob.glob("C:\\Users\\Gadget\\Documents\\*.docx") but are better off using glob.glob("C:/Users/Gadget/Documents/*.docx") - the only real issue to avoid is the fact that Windows paths are case insensitive so names that differ only in case changes can & will collide. -----Original Message----- From: Mike Miller <python-ideas@mgmiller.net> Sent: 24 March 2020 21:39 To: python-ideas@python.org Subject: [Python-ideas] Re: About python3 on windows On 2020-03-24 11:58, Eryk Sun wrote:
On 3/24/20, Mike Miller <python-ideas@mgmiller.net> wrote:
C:\Users\User>python3 (App store loads!!)
If installed, the app distribution has an appexec link for "python3.exe" that actually works.
C:\Python38>dir Volume in drive C has no label. [snip] Note there is no python3.exe binary.
You can manually copy or symlink python.exe to python3.exe in the installation directory and venv "Scripts" directories. However, it will only be used on the command line, and other contexts that search PATH. Currently the launcher will not use it with a virtual "env" shebang. The launcher will search PATH for "python", but not "python3".
Thanks. Sure, there are many ways to fix this manually, or work around it. Would be great if it was consolidated, with one command "to rule them all." _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F2NEZJ... Code of Conduct: http://python.org/psf/codeofconduct/
On 3/25/20, Steve Barnes <GadgetSteve@live.co.uk> wrote:
Of course if, rather than creating symlinks, you create a batch file called python3.bat and containing the line: @py -3 %*
Batch scripts execute via cmd.exe, with an attached console, and when Ctrl+C is typed they display a "Terminate batch job (Y/N)?" prompt when cmd.exe resumes. This makes them a poor substitute for a link. If the link is created beside "py.exe", it's better to use a relative symlink. If the link is in another directory, use a shell link (i.e. shortcut). Set the command to run as "C:\Windows\py.exe -3", or wherever "py.exe" is installed. The shell API will pass command line arguments. Clear the shortcut's "start in" field in order to inherit the parent's working directory. Add ".LNK" to PATHEXT to be able to run "python3" on the command line instead of requiring "python3.lnk".
It is also worth mentioning that python (and the py launcher) both accept windows paths (\ separated) and *nix paths (/ separated) from the command line and that from within scripts the *nix path separator is to be preferred
That's generally true. Note however that the only reliable way to access a path that exceeds MAX_PATH characters (260, or less depending on context) is with a \\?\ extended path, which must use backslash. (Python 3.6+ does support long normal paths in Windows 10, but this capability has to be enabled at the system level. Plus many scripts and applications still need to support Windows 7 and 8.) An extended path is also required to open files with certain reserved names such as DOS devices (e.g. "con" or "nul:.txt") and names that end with spaces and dots (e.g. "spam. . ."). But please do not use an extended path in order to assign reserved names. It just causes needless problems.
glob.glob("C:/Users/Gadget/Documents/*.docx") - the only real issue to avoid is the fact that Windows paths are case insensitive so names that differ only in case changes can & will collide.
A FAT32 filesystem is case insensitive in Unix (e.g. on a portable drive), so this problem isn't limited to Windows. It's just more common in Windows. Also, an NTFS directory tree can be flagged as case sensitive in Windows 10, but thankfully this isn't commonly used, even by developers.
On 3/24/20, Mike Miller <python-ideas@mgmiller.net> wrote:
On 2020-03-24 11:58, Eryk Sun wrote:
You can manually copy or symlink python.exe to python3.exe in the installation directory and venv "Scripts" directories. However, it will only be used on the command line, and other contexts that search PATH. Currently the launcher will not use it with a virtual "env" shebang. The launcher will search PATH for "python", but not "python3".
Thanks. Sure, there are many ways to fix this manually, or work around it.
Except it's not necessarily what the original post wants. The OP wants the shebang "#!/usr/bin/env python3" to "work everywhere by default", for which I assume it's implied that it should work consistently everywhere. I'd prefer for the launcher's env search to also support versioned "pythonX[.Y][-32|-64]" commands such as "python3". I'd also prefer the env search to check the user and system "App Paths" key [1] if the name isn't found in PATH. Each subkey of "App Paths" is the name of a command such as "python3.exe", for which the fully-qualified executable filename is the key's default value. This is the Windows shell API equivalent of creating symlinks in "~/.local/bin" and "/usr/bin" on Unix systems. ShellExecuteExW checks "App Paths", but the launcher has to use CreateProcessW, which is beneath the shell API.
Would be great if it was consolidated, with one command "to rule them all."
I'm in favor of "py" becoming the cross-platform command to run Python from the command line, since there's already a lot of inertia in that direction on Windows. Brett Cannon is working on a Unix version [2]. [1]: https://docs.microsoft.com/en-us/windows/win32/shell/app-registration#using-... [2]: https://crates.io/crates/python-launcher
On Mon, Mar 23, 2020 at 05:59:41PM -0000, Frédéric De Jaeger wrote:
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
Its probably less than 99% by now, but still quite high. Do I understand you that "python" (without a full pathname) is supported on Windows? If I understand Brett's later comment, I expect that by default your Windows users will need to type the full pathname, since Python isn't added to the PATH. Are you familar with the py.exe Windows launcher? Does it help? https://www.python.org/dev/peps/pep-0397/ Perhaps you can just have your Windows users call "py myscript.py" and your non-Windows users call "myscript.py" (after setting the appropriate hashbang referring to python3).
At the moment, we have scripts that run under version 2 when run by a linux user and version 3 on windows. This works by pure luck.
If I have understood your problem correctly, I think the smallest, least invasive change to have this all "just work" is: - have all your scripts specify "python3" in their hashbang rather than "python"; - add a "python3 --> python" alias on Windows. Which I think is what you are asking here:
If the standard python distro would just provide a simple `python3` binary/alias, then all the stars would align perfectly. the basic shebang
#! /usr/bin/env python3
would work everywhere by default, without requiring any tweaking (install a python3 alias on windows, or ask linux users to change the default `python` symlink)
In other words, your idea is for Python on Windows to support "python3" as well as "python". Is that correct? I'm not a Windows user, so I don't know if there is a downside to that idea, but if your analysis is correct is seems like a good, simple idea. -- Steven
Steven D'Aprano wrote:
On Mon, Mar 23, 2020 at 05:59:41PM -0000, Frédéric De Jaeger wrote:
The issue is: There is no reliable way to launch a python script. The command: python myscript.py
launches python3 on windows and python2 on 99% of the unix market. Its probably less than 99% by now, but still quite high. Do I understand you that "python" (without a full pathname) is supported on Windows? If I understand Brett's later comment, I expect that by default your Windows users will need to type the full pathname, since Python isn't added to the PATH.
I suppose we tell all our windows users (which I'm not) to be sure to have python in their PATH. So they should have used the installer facility for that.
Are you familar with the py.exe Windows launcher? Does it help? https://www.python.org/dev/peps/pep-0397/ Perhaps you can just have your Windows users call "py myscript.py" and your non-Windows users call "myscript.py" (after setting the appropriate hashbang referring to python3).
One of our constraint is that we use Cygwin's bash and now, every user relies on the shebang. The problem reduce to this. Assuming you are in a bash window (whether on cygwin or ubuntu 18, or mac os) and you do this: > ./myScript.py How do you write the shebang so it runs reliably python3 with the minimal amount of energy spent configuring the system. So, `py` launcher does not seem to solve our problem.
In other words, your idea is for Python on Windows to support "python3" as well as "python". Is that correct?
Yes, that would be ideal. All our scripts would work out of the box, given our workflow. From that doc: https://docs.python.org/3/using/windows.html#the-microsoft-store-package It seems `python3.exe` is available when we installed python from the windows store. So maybe a solution is that we tell our employees to install that version instead. That is just a bit odd the _traditional installer_ does not do the same thing.
On 3/24/2020 6:58 AM, Frédéric De Jaeger wrote:
One of our constraint is that we use Cygwin's bash and now, every user relies on the shebang. The problem reduce to this. Assuming you are in a bash window (whether on cygwin or ubuntu 18, or mac os) and you do this:
> ./myScript.py
How do you write the shebang so it runs reliably python3 with the minimal amount of energy spent configuring the system.
Why don't you just install the cygwin version of python3? That will put python3 in your path, and I think solve your problem. That's the setup I use. Cygwin should make it easier to have Windows look like Unix, not harder. Eric
On Tue, 24 Mar 2020 at 11:39, Eric V. Smith <eric@trueblade.com> wrote:
Cygwin should make it easier to have Windows look like Unix, not harder.
In my experience, only if you use Cygwin for everything (so I agree, Frédéric should probably install cygwin Python). Integrating native applications and Cygwin isn't hard, but it's not seamless, either (and honestly, that shouldn't really be surprising to anyone - Unix and Windows are very different environments, after all). There's also the option (if Frédéric's users are on Windows 10) of using Ubuntu on Windows for a 100% compatible Unix environment. Paul
On 23 Mar 2020, at 17:59, Frédéric De Jaeger <fdejaeger@novaquark.com> wrote:
Hi all,
There is a recurring problem in my company where we use python in various places (python3). We do cross platform development windows/linux and our python scripts need to run everywhere. Some scripts are launched manually in a terminal. Others are launched via windows' gui interface. Others are launched through our build process (cmake based, but also manual Makefile) And others are launched via bash scripts. And possible several other scenario I've forgot.
On windows, most users use Cygwin to do their terminal based business (`git`, `cmake`, ...).
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
The command
python3 myscript.py
The windows version would be py myscript.py If you have python 2 and 3 installed then py -3 myscript py.exe can run any installed version of python and if only one is installed that it will default to the one of only. re: use venv Do not see the need to add venv complexity to the mix just to start an installed python. The py.exe can run any installed version of python. I use that all the time when testing against multiple versions. py -2.7-32 myscript.py py -2.7-64 mysctipt.py ... py -3.7-64 myscript.py
does not run on windows with the latest python distribution I've played with (sorry if it has been fixed recently, this whole mail becomes pointless).
Human can learn which command to run, it's ok. But for all other invocations context, this becomes very annoying.
Switching between linux and Windows requires all sorts of different UI to be aware of. How to get a terminal prompt, how to get a directory listing, etc.
Surprisingly, `cmake` is the more friendly, since `FindPython` will returns a python3 first.
At the moment, we have scripts that run under version 2 when run by a linux user and version 3 on windows. This works by pure luck.
If the standard python distro would just provide a simple `python3` binary/alias, then all the stars would align perfectly. the basic shebang
#! /usr/bin/env python3
This does work out of the box because py.exe is run when you execute a .py in the CMD. C:\> my-py3-script.py Note: Installing python2 seems to prevent py.exe getting setup for .py files. You can check by doing: assoc .py ftype Python.File If Python.File is not using py.exe then you can fix that with this command from an Admin CMD. ftype Python.File="C:\windows\py.exe" "%1" %* Barry
would work everywhere by default, without requiring any tweaking (install a python3 alias on windows, or ask linux users to change the default `python` symlink)
I'm sure, I'm far from being the first user complaining about that. Sorry if the request has been been made numerous time before.
What it the status on this point ?
Thanks a lot.
Fred _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PTYLAO... Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Mar 24, 2020 at 10:21:33AM +0000, Barry Scott <barry@barrys-emacs.org> wrote:
On 23 Mar 2020, at 17:59, Fr??d??ric De Jaeger <fdejaeger@novaquark.com> wrote: The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
The command
python3 myscript.py
The windows version would be
py myscript.py
That is, **in addition** to ``python`` and ``python3`` Fred should learn, use and teach ``py``? Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
This does work out of the box because py.exe is run when you execute a .py in the CMD.
Yep, but the constraint is it has to run in Cygwin's bash terminal. Does it honor windows file associations ? I have some doubts (sorry I don't have a windows available to test the hypothesis). If it works, this is a valid solution. Probably the best option for us is to install python via Cygwin, as already suggested. We are in a kind of no man's land playing with Cygwin and pure windows python packages and expecting the linux behavior. I imagine this is the reason why people don't complain that much about it. Python is not critical in our business, the problem went largely unnoticed until our scripts become complicated enough and started to use python3 only features. Fred
On 3/24/20, Barry Scott <barry@barrys-emacs.org> wrote:
If you have python 2 and 3 installed then
py -3 myscript
"myscript" may have a shebang that runs the "python2" virtual command (e.g. "#!python2" or "#!/usr/bin/python2") because the script requires 2.x, but using "-3" will override it to run the "python3" virtual command instead. The "python2" virtual command defaults to the highest installed version of 2.x. The "python3" virtual command defaults to the highest installed version of 3.x. Without a shebang, the "python" virtual command defaults to the highest installed 3.x, but with a shebang it defaults to the highest installed 2.x. py without a script (e.g. the REPL or -c or -m) uses the "python" virtual command, so it defaults to the highest installed 3.x. The version to run for the "python" virtual command is set via the PY_PYTHON environment variable, whether or not there's a shebang. Similarly the version to run for the "python2" and "python3" virtual commands is set via PY_PYTHON2 and PY_PYTHON3. No sanity checks are performed, so "PY_PYTHON2=3" is allowed.
#! /usr/bin/env python3
This does work out of the box because py.exe is run when you execute a .py in the CMD.
The "/usr/bin/env" virtual command is expected to search PATH. py does search PATH for "/usr/bin/env python", but for "/usr/bin/env python3" it uses the "python3" virtual command instead of searching, since standard Python installations and virtual environments do not include "python3.exe". There's an open issue for this, but there's no consensus.
You can check by doing:
assoc .py ftype Python.File
If Python.File is not using py.exe then you can fix that with this command from an Admin CMD.
ftype Python.File="C:\windows\py.exe" "%1" %*
CMD's internal assoc and ftype commands are no longer useful in general. They date back to Windows NT 4 (1996) and have never been updated. As far as I know, Microsoft has no up-to-date, high level commands or PowerShell cmdlets to replace assoc and ftype. In PowerShell I suppose you could pInvoke the shell API (e.g. AssocQueryStringW). assoc and ftype only access the basic system file types and progids in "HKLM\Software\Classes", not the HKCR view that merges in and prefers "HKCU\Software\Classes" or various other subkeys such as "Applications" and "SystemFileAssociations". Also, they don't account for the cached and locked user choice in the shell. For example, assoc may tell you that ".py" is associated with the "Python.File" progid. But it's potentially wrong. It's not aware of an association set in "HKCU\Software\Classes\.py" (e.g. set by a per-user Python installation). It's also not aware of a locked-in user choice (i.e. the user selected to always use a particular app), if one is set, in "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice". The user should set the file association using the settings dialog for choosing default apps by file type or the "open with" dialog on the right-click context menu. If the application chooser doesn't include a Python icon with a rocket on it, then probably the launcher and Python.File progid are installed for all users, but there's a per-user association in "HKCU\Software\Classes\.py" that's overriding the system setting. Deleting the default value in the latter key should restore the launcher to the list of choices.
On 23Mar2020 17:59, Frédéric De Jaeger <fdejaeger@novaquark.com> wrote:
There is a recurring problem in my company where we use python in various places (python3). We do cross platform development windows/linux and our python scripts need to run everywhere. Some scripts are launched manually in a terminal. Others are launched via windows' gui interface. Others are launched through our build process (cmake based, but also manual Makefile) And others are launched via bash scripts. And possible several other scenario I've forgot.
On windows, most users use Cygwin to do their terminal based business (`git`, `cmake`, ...).
The issue is: There is no reliable way to launch a python script.
The command:
python myscript.py
launches python3 on windows and python2 on 99% of the unix market.
The command
python3 myscript.py
does not run on windows with the latest python distribution I've played with (sorry if it has been fixed recently, this whole mail becomes pointless). [...] If the standard python distro would just provide a simple `python3` binary/alias, then all the stars would align perfectly. the basic shebang
#! /usr/bin/env python3
would work everywhere by default, without requiring any tweaking (install a python3 alias on windows, or ask linux users to change the default `python` symlink)
I'm sure, I'm far from being the first user complaining about that. Sorry if the request has been been made numerous time before.
I'm sticking my oar in here because this whole thread seems to sidestep Frédéric's question: WHY isn't there a python3.exe installed with a version 3 Windows python install? With that, the "#!/usr/bin/env python3" and command line "python3" invocations would Just Work. There might be fiddling around locating the specific python3 (see Eryk's long posts about how the launcher and various environments do their searching), but at least the user would always get a version 3 Python, and if there's just one Python 3 on the box, they always get the _correct_ Python 3. The point isn't "what Python does 'python' get you?", it is "why can't we make 'python3' find a Python 3 universally, including from a shebang?" It seems to me that there is a deliberate choice to _not_ install the "python3" executable name when installing Python 3 on Windows, and to my eye that is/was a _bad_ choice. I would like to see a good explaination as to why that choice was made. Choosing Python 3 specificly is an important choice for many scripts because 2->3 was a breaking change. Cheers, Cameron Simpson <cs@cskk.id.au>
On Thu, 26 Mar 2020 at 22:11, Cameron Simpson <cs@cskk.id.au> wrote:
It seems to me that there is a deliberate choice to _not_ install the "python3" executable name when installing Python 3 on Windows, and to my eye that is/was a _bad_ choice. I would like to see a good explaination as to why that choice was made.
I don't think that's quite right. Originally, the choice was to install "python", and that was it. That was true on Unix as well. When Python 3 came along, Unix needed to have both python (=python 2) and python3. But the reasons for that (distros using python 2 for system scripts) didn't apply on Windows, so there was no need for a change there. Maybe that was a mistake, and compatibility with Unix should have been seen as more important than maintaining the existing model on Windows. But IMO, it wasn't so much a deliberate choice to not provide python3, more of a lack of any decision to do so. The fact that the situation hasn't been reviewed, and hasn't been changed, is likely mostly just inertia. That, plus the fact that there simply haven't been that many complaints. Sure, this thread has generated a lot of discussion, but it's just one thread, triggered by one poster with a very specific situation. I'm not saying that we should ignore the issue - I doubt that shipping a python3.exe is a huge effort in practice - but I'm not aware that this is as widespread an issue as all that. So honestly, I don't think there's any useful information or explanation to be had from the history. Unless there's been a previous request to add python3.exe that got blocked, I think we just sort of got here by *not* making any specific decisions.
Choosing Python 3 specificly is an important choice for many scripts because 2->3 was a breaking change.
Well, certainly for some scripts. But not * If you don't share your script * If you only share scripts between people using the same Python version * If you only use a single OS (you can use OS-specific approaches to choose a Python version) * If you bundle your script into a wheel or application It's really only scripts that need to be shared as simple scripts between machines with a variety of operating systems and a variety of Python versions that have a really difficult problem to address here. I don't know what proportion of scripts that would be. However, I also don't see that how many scripts are affected is any reason *not* to make things easier for them, if doing so is straightforward. Maybe someone should just raise a PR for 3.9, to include versioned exes in the Windows installers (and the various other Windows distributions)? If there *are* any good reasons to object, they'd come up in PR review, I imagine. Paul
participants (16)
-
Andrew Barnert -
Barry Scott -
Brett Cannon -
Cameron Simpson -
Chris Angelico -
Christopher Barker -
Eric V. Smith -
Eryk Sun -
Frédéric De Jaeger -
Kyle Stanley -
Mike Miller -
Oleg Broytman -
Paul Moore -
Rhodri James -
Steve Barnes -
Steven D'Aprano