On Mon, Mar 23, 2020 at 6:19 PM Oleg Broytman <p...@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/ p...@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-le...@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/VMZBOM6SOWX3LPSKQAXMP5FUE45QSWYH/ > 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/CGPYT2SKDHLHLUW7A64AI6O3M3WWGETX/ Code of Conduct: http://python.org/psf/codeofconduct/
