Re: Fwd: Installation hell
Personally I use winpython: https://winpython.github.io/ That have all the scientific packages already available. It can run without being installed and uses spyder as an IDE (for small projects it's ok). And, I can import pygame (even though I have not tested if everything works) in python 3.11. As I'm using it for science projects I find it perfect. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/20/2022 8:11 AM, Eryk Sun wrote: [snipped] I know we're not here to bash Windows, but... drive letters really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. Microsoft won't get rid of them for backwards compatibility reasons, aside from the sheer difficulty of changing all that code. The company has always been very industrious about keeping backwards compatibility for Windows. I have compiled Delphi Windows GUI code from 2003 and even earlier that still runs, as one example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/22, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > >> @echo off >> setlocal >> : Find effective drive for this file. >> set ed=%~d0 >> path %ed%\python37\Scripts;%ed%\python37;%PATH% For reference, in case not everyone on the list knows what "%~d0" means, the CMD shell supports extracting the drive (d), path (p), name (n), and extension (x) components of a path name that's stored in a parameter such as "%0". The full path (f) is resolved beforehand. For example: C:\Temp>set var=spam\eggs.py C:\Temp>for %c in (%var%) do @echo drive: "%~dc" drive: "C:" C:\Temp>for %c in (%var%) do @echo path: "%~pc" path: "\Temp\spam\" C:\Temp>for %c in (%var%) do @echo name: "%~nc" name: "eggs" C:\Temp>for %c in (%var%) do @echo extension: "%~xc" extension: ".py" C:\Temp>for %c in (%var%) do @echo full path: "%~dpnxc" full path: "C:\Temp\spam\eggs.py" C:\Temp>for %c in (%var%) do @echo full path: "%~fc" full path: "C:\Temp\spam\eggs.py" > So much easier to do on a Unix-like system, where you don't need to > concern yourself with "effective drive" and can simply use relative > paths. A relative path in the PATH environment variable would depend on the current working directory. Surely the added paths need to be absolute. However, Thomas didn't have to reference the drive explicitly. The expression "%~dp0" is the fully-qualified directory of the executing batch script, and an absolute path can reference its ancestor directories using ".." components. > I know we're not here to bash Windows, but... drive letters > really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. The drive concept is deeply ingrained in the design of NT, the Windows API, shells, and applications. While assigning drive names "A:", "B:", and "D:" to "Z:" can be avoided, the system volume, i.e. drive "C:", still has to be accessed in the normal way, or using another one of its persistent names, such as r"\\?\BootPartition". The latter still uses the filesystem mount point on the root path of the device (e.g. "?\\BootPartition\\"), which you probably take issue with. That's a deeply ingrained aspect of Windows. Even mount points set on filesystem directories are actually bind mount points that ultimately resolve to the root path on the volume device (e.g. "\\Device\\HarddiskVolume4\\"). This differs from how regular mount points work on Unix, for which a path like "/dev/sda1/etc" is gibberish. Below I've outlined the underlying details of how logical drives (e.g. "C:"), UNC shares (e.g. r"\\server\share"), other device names, and filesystem mount points are implemented on NT. --- NT Device Names In contrast to Unix, NT is organized around an object namespace, not a root filesystem. Instances of many object types can be named. Some named object types also support a parse routine for paths in the namespace of an object (e.g. the configuration manager's registry "Key" type and the I/O manager's "Device" type). The object manager uses two object types to define the object namespace: Directory and Symbolic Link. Directory objects form the hierarchical tree. At the base of the tree is the anonymous root directory object (i.e. "\\"). A directory is implemented as a hashmap of named objects. A directory can be set as the shadow of another directory, creating a union directory for name lookups. Unless otherwise stated, the following discussion uses "directory" and "symlink" to refer to a directory object and a symbolic-link object, respectively -- not to a filesystem directory or filesystem symlink. A canonical NT device name (e.g. "C:", "PIPE", "UNC") is implemented in the object namespace as a symlink that targets the path of a real device object. The real device is typically in the r"\Device" directory. A canonical device name might be a persistent name for an enumerated device (e.g. "C:" -> r"\Device\HarddiskVolume2"). In some cases the real device name is persistent, but it's different from the canonical name (e.g. "PIPE" -> r"\Device\NamedPipe", or "UNC" -> r"\Device\Mup"). The symlink that implements a canonical device name is created either in the r"\Global??" directory or in a directory that's used for local device names in a given logon session (e.g. r"\Sessions\0\DosDevices\"). The global device directory generally contains system devices. Mapped drives and substitute drives typically use a local device directory, so users don't have to worry about conflicting drive assignments in these cases. The global device directory is the shadow of each local device directory, forming a union for name lookups. If the same device name is defined in both the local and global directories, the local device name takes precedence. However, each local device directory also contains
OT: ~gohlke [Was: Installation hell]
On 20/12/2022 9:28 am, Mats Wichmann wrote: On 12/19/22 14:47, Eryk Sun wrote: If you search a bit deeper, you'll find a site with unofficial Windows builds of many packages, including pygame for Python 3.11: https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame Semi-OT: that's been a superb resource, but apparently it's no longer maintained - internet scuttlebutt suggests the project which let it exist has lost funding. The link above is a mirror, marked "Archived", and I can't see there's been any addition since July 1. (sadly... I happen to need an lxml build for experimenting with 3.12 alphas, and that's an absolute bear to build for WIndows - I've never cracked it) That is dreadful news! Windows as a dev platform is dead without it. That is serious. Back on topic - Installation hell I use Windows for historic reasons related to needing to support 99% of my customers/dependents who also use it. I'm the only one who also uses Linux - but only non-GUI Linux. Windows works for me as a dev platform because there are so many talented Python people out there who make it work. It would be impossible otherwise. I would be forced to to learn two GUIs if I had to develop on Linux. I'm here to tell you that dev and production on different OSs works without a hitch! For me. Whoever wrote the installation docs for Windows did a great job. All the bases and options are covered. Absolutely no-one could complain that any pertinent detail has been omitted. Some marketing research is indicated. The OP who started this thread could define themself in exquisite detail so that installation infrastructure including documentation can be developed to suit that market exemplar. I think there are several separate markets. Eg., for someone like me ... locked into Windows (but not Microsoft otherwise) and needing to target Linux web servers. That would allow a branching of the installation docs to home in, say, on virtual envs and multiple Python installations in the root of drive C: (well away from "Program files") and so on. If the OP says they are an educated computer scientist they could become a hero and write up a tightly focused set of docs (extracted from the comprehensive canonical docs) which assume their particular "market", for want of a better term. The PSF might recognise the effort and be able to promote such a high interest from Windows Python devs into funding for Chris Gohlke. Cheers Mike -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Just ask and I'll send it to you. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On Tue, 20 Dec 2022 at 10:01, Thomas Passin wrote: > > On 12/19/2022 5:16 PM, Chris Angelico wrote: > > On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > >> FWIW, I once set up a Python installation so that it could run from a > >> USB stick (Windows only). My launcher was a batch file that contained > >> the following: > >> > >> @echo off > >> setlocal > >> : Find effective drive for this file. > >> set ed=%~d0 > >> path %ed%\python37\Scripts;%ed%\python37;%PATH% > >> set PYTHONUSERBASE=%ed%\user\python > >> set HOME=%ed%\user\python > >> call python %* > >> endlocal > >> > > > > So much easier to do on a Unix-like system, where you don't need to > > concern yourself with "effective drive" and can simply use relative > > paths. I know we're not here to bash Windows, but... drive letters > > really need to just die already. > > Considering that this was for a removable drive, the launcher needed to > know its own location, which might change from one instance to another. > If you look at the code above, you won't find an obvious drive letter. > You would need to do the equivalent on Linux. The Windows drive letter > is just not relevant here. The only thing that's relevant is the *path*. Everything can be made relative to a single directory. On Unix-like systems, any relative path can be made absolute with reference to a single directory - most commonly the current working directory, of which there is precisely one. On Windows, there is the current working directory, plus twenty-six ADDITIONAL reference directories, plus a current drive (I'm not certain whether "current working directory" is the same as "current drive + current directory on that drive", so maybe there's one fewer than this). If you create a Python virtual environment without symlinks (eg "python3 -m venv env --copies"), you can run Python scripts using that environment simply by invoking the corresponding Python interpreter, regardless of the actual path. Trivially easy, because it's simply relative paths. On Tue, 20 Dec 2022 at 10:03, Grant Edwards wrote: > > On 2022-12-19, Chris Angelico wrote: > > > So much easier to do on a Unix-like system, where you don't need to > > concern yourself with "effective drive" and can simply use relative > > paths. I know we're not here to bash Windows, but... drive letters > > really need to just die already. > > They needed to "die already" 40 years ago. I was a Unix user before > MS-DOS came out, and I was rather stunned by the whole drive letter > thing. It seemed like such a giant step backwards. I figured that once > hard drives became common, drive letters would die. Nope, they're > still failing strong! They feel like part of an old style of concrete identifiers, like working with direct memory addresses (as opposed to virtual memory pages), until you realise that even MS-DOS had a special hack that let a single physical drive behave as both A: and B: with system-provided prompts "please insert disk for drive A/B" when needed. And with the SUBST and JOIN commands, you could - again, even in MS-DOS - mount directories as drives or drives as directories. (I don't remember what happened if you tried to use both at once to have a directory appear in a different location - the equivalent of a bind mount. Might have worked.) People could have destroyed drive letters by just always turning them into directories, and then comfortably moving to a Unix-like mount system, but since that didn't happen, generations of Windows users have grown up with the expectation that drive letters are a thing. And that leads to myriad problems. Until Steve Dower got involved with the Python installers, there were periodic issues resulting from certain combinations of (a) installing Python somewhere other than the C: drive, (b) using pip from somewhere other than the C: drive to install packages, and (c) attempting to use those packages from somewhere other than C:. I don't remember exactly what the solutions were (I want to say that "use explicit paths" was part of it, but this was a while ago and my memory of other people's problems isn't the greatest), but it was often a mess. Chrsia -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 2022-12-19, Chris Angelico wrote: > So much easier to do on a Unix-like system, where you don't need to > concern yourself with "effective drive" and can simply use relative > paths. I know we're not here to bash Windows, but... drive letters > really need to just die already. They needed to "die already" 40 years ago. I was a Unix user before MS-DOS came out, and I was rather stunned by the whole drive letter thing. It seemed like such a giant step backwards. I figured that once hard drives became common, drive letters would die. Nope, they're still failing strong! -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 5:16 PM, Chris Angelico wrote: On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: FWIW, I once set up a Python installation so that it could run from a USB stick (Windows only). My launcher was a batch file that contained the following: @echo off setlocal : Find effective drive for this file. set ed=%~d0 path %ed%\python37\Scripts;%ed%\python37;%PATH% set PYTHONUSERBASE=%ed%\user\python set HOME=%ed%\user\python call python %* endlocal So much easier to do on a Unix-like system, where you don't need to concern yourself with "effective drive" and can simply use relative paths. I know we're not here to bash Windows, but... drive letters really need to just die already. Considering that this was for a removable drive, the launcher needed to know its own location, which might change from one instance to another. If you look at the code above, you won't find an obvious drive letter. You would need to do the equivalent on Linux. The Windows drive letter is just not relevant here. (and I thought we weren't going keep on bashing non-preferred operating systems). -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 12/19/22 14:47, Eryk Sun wrote: If you search a bit deeper, you'll find a site with unofficial Windows builds of many packages, including pygame for Python 3.11: https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame Semi-OT: that's been a superb resource, but apparently it's no longer maintained - internet scuttlebutt suggests the project which let it exist has lost funding. The link above is a mirror, marked "Archived", and I can't see there's been any addition since July 1. (sadly... I happen to need an lxml build for experimenting with 3.12 alphas, and that's an absolute bear to build for WIndows - I've never cracked it) -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > FWIW, I once set up a Python installation so that it could run from a > USB stick (Windows only). My launcher was a batch file that contained > the following: > > @echo off > setlocal > : Find effective drive for this file. > set ed=%~d0 > path %ed%\python37\Scripts;%ed%\python37;%PATH% > set PYTHONUSERBASE=%ed%\user\python > set HOME=%ed%\user\python > call python %* > endlocal > So much easier to do on a Unix-like system, where you don't need to concern yourself with "effective drive" and can simply use relative paths. I know we're not here to bash Windows, but... drive letters really need to just die already. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 4:54 PM, Thomas Passin wrote: On 12/19/2022 3:34 PM, j wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Yes, I've had a few of those, just not with Python so far. One problem with a list like this is that if other people don't have the problem or can't make it happen, then they don't have any suggestions based on personal experience. So they can't be helpful. In this issue, I'm in that category. In that situation, we (the list-people, I mean) need good information to have a chance of being helpful. But I've observed that many requestors for help like this - especially installation issues - don't provide any useful particulars. That makes it seem like they don't understand what they are doing, and folks would like them to do their homework and think about what it would take for other people to have a chance of helping. Would you try to cook a meal, and then say "I followed the recipe and it didn't work, please help"? It's impossible. But I've seen this kind of question over and over on this list. I did once have a Python installation problem. The installed Python executable worked, but later I ran into some permissions problem. I had installed for "everyone", so it installed into Program Files, and apparently somewhere along the way I had done something odd to the permissions for that directory. I was never sure what. I uninstalled, and since then I have always installed new versions for just one user (me). Never a problem since. I'm sorry to say that I have never tried an embedded install, and I don't know what's different about one. Maybe I'll try one now, just to know. FWIW, I once set up a Python installation so that it could run from a USB stick (Windows only). My launcher was a batch file that contained the following: @echo off setlocal : Find effective drive for this file. set ed=%~d0 path %ed%\python37\Scripts;%ed%\python37;%PATH% set PYTHONUSERBASE=%ed%\user\python set HOME=%ed%\user\python call python %* endlocal I suppose anyone trying to use an embedded version of Python would have to set up some environmental variables in a similar way. Note that I used the "user" directory on the USB stick as a home directory for the installation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 3:34 PM, j wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Yes, I've had a few of those, just not with Python so far. One problem with a list like this is that if other people don't have the problem or can't make it happen, then they don't have any suggestions based on personal experience. So they can't be helpful. In this issue, I'm in that category. In that situation, we (the list-people, I mean) need good information to have a chance of being helpful. But I've observed that many requestors for help like this - especially installation issues - don't provide any useful particulars. That makes it seem like they don't understand what they are doing, and folks would like them to do their homework and think about what it would take for other people to have a chance of helping. Would you try to cook a meal, and then say "I followed the recipe and it didn't work, please help"? It's impossible. But I've seen this kind of question over and over on this list. I did once have a Python installation problem. The installed Python executable worked, but later I ran into some permissions problem. I had installed for "everyone", so it installed into Program Files, and apparently somewhere along the way I had done something odd to the permissions for that directory. I was never sure what. I uninstalled, and since then I have always installed new versions for just one user (me). Never a problem since. I'm sorry to say that I have never tried an embedded install, and I don't know what's different about one. Maybe I'll try one now, just to know. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. Yes, that's true. Lack of clear information isn't helpful, either. Well this is getting too long, and not directly helping with any of your problems. I hope it may be informative for others who want to ask for help. To be able to help someone, I have to understand just what they were trying to do, what they did, what happened that caused them to think their efforts failed, and what error messages the system emitted. That may not be enough either, but it's a required starting point. Without this kind of information, people who want to help feel frustrated. jan On 19/12/2022 17:55, Thomas Passin wrote: On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 12/18/22, Jim Lewis wrote: > > Sometimes it's a path issue. For whatever reason, Python installations on Windows lack versioned executable names (except for the Microsoft Store distribution). Thus adding multiple installations to PATH doesn't help unless "python.exe" is manually linked or copied to versioned names, e.g. "python3.11.exe" -> "python.exe" and "python3.exe" -> "python.exe". In this case, the first installation in PATH is the default for running "python" and "python3". Using the "py.exe" launcher is the more general and preferred solution. It allows running any registered Python installation. It's also the installed handler for the ".py" file type, and it supports Unix-style shebangs. > Or exe naming confusion: python, python3, phthon311, etc. I don't understand what's supposedly confusing here. Here are some commands to help discover what "py" or "python" commands and installations are available. * CMD: where py*.exe * PowerShell: get-command py*.exe * Python launcher: py --list-paths > Or library compatibility issues - took an hour to find out that > pygame does not work with the current version of python. It should be a trivial task to discover that wheel packages for pygame aren't currently available for Python 3.11. It is not unreasonable to expect Python developers to familiarize themselves with pip and PyPI. If you search a bit deeper, you'll find a site with unofficial Windows builds of many packages, including pygame for Python 3.11: https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame Otherwise, while building some packages from source can be quite involved and difficult, I'd expect anyone with a degree in computer science to be able to build pygame if necessary. They even provide a simple guide: https://www.pygame.org/wiki/CompileWindows > Then the kludgy PIP app and using a DOS box under Windows with > command prompts which is ridiculous. How is pip "kludgy" (i.e. sloppy, hasty, shoddy, or inelegant)? How is using a command-line interface "ridiculous"? Many programmers and system administrators actually prefer using command-line interfaces and text user interfaces (TUI) for many if not most development and administration tasks. It's a matter of opinion. --- Nerdy operating system discussion... > using a DOS box under Windows The term "DOS box" refers to a virtual machine running 16-bit MS-DOS in virtual 8086 (v86) mode under Windows 3.1 or Windows 9x, with the MS-DOS keyboard and display drivers hooked to redirect I/O to a desktop window. There is no "DOS box" in Windows NT systems. Windows client systems switched to NT starting with Windows XP. Thus the term "DOS box" is about two decades out of date. Also, "DOS" is not synonymous with a command-line interface shell (e.g. the 16-bit MS-DOS shell, "COMMAND.COM"). A "Disk Operating System" is one that supports disk drives and filesystems, which includes most operating systems from the late 1960s onward (e.g. DOS/360 from 1966). There were several DOS systems for personal computers in the 1980s, such as Apple ProDOS, Atari DOS, Tandy TRSDOS, Commodore DOS, and Microsoft MS-DOS. A DOS system can use a graphical shell, such as running Windows 1.0 (1985) on MS-DOS. The "python.exe" executable is a Windows application that's flagged to require a console session. If it doesn't inherit a console session, then the system allocates one automatically. However, any Windows application can allocate, attach to, and detach from a console session via AllocConsole(), AttachConsole(), and FreeConsole(). Prior to Windows 7, each console session in the current NT session is hosted on threads in the subsystem process for Windows, "csrss.exe". Starting with Windows 7, console sessions are hosted by instances of "conhost.exe". The console host also implements a builtin terminal window for command-line interface (CLI) and text user interface (TUI) applications. (A console session can be allocated without a terminal window if a console application is spawned with the creation flag CREATE_NO_WINDOW.) Prior to Windows 10, the connection between a console session and its terminal is hardwired in the console host. This makes it difficult to implement an alternate terminal, though some alternate terminals have managed to do so in creative ways (e.g. ConEmu). Starting with Windows 10, alternate terminals can use an open source implementation of the console host, named "openconsole.exe". The most important example is Microsoft's "Windows Terminal". Starting with Windows 11, an alternate terminal can also register as the default terminal for console applications. For example, if Windows Terminal is set as the default terminal, then running "python.exe" from Explorer opens a new tab in Terminal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
I was suggesting a possible resource while making it clear I am not Windows savvy. My avoidance of Windows has nothing to do with Python, so there is no need to discuss it here. If I don’t care which Python I’m using, I’ll type python3. If I want3.9, python3.9. python3 -V tells me the default on that system. (It varies across our servers). If a Python package isn’t available in the mainline Ubuntu repository (python3-whatever), I’m creating a virtual environment. It just saves trouble in the long run. I have this in ~/bin to create an environment. I’m slowly moving projects to the pyproject.toml because pip is complaining about the setup.py installs. #!/bin/bash VERS=3.8 #default version VENV=venv #default environment name if [ $# -gt 0 ]; then VERS=$1 fi if [ $# -gt 1 ]; then VENV=$2 fi PYTHON=python$VERS echo $PYTHON $PYTHON -m venv $VENV ./$VENV/bin/pip install -U pip ipython if [ -e requirements.txt ]; then ./$VENV/bin/pip install -r requirements.txt fi if [ -e setup.py ]; then ./$VENV/bin/python setup.py install fi if [ -e pyproject.toml ]; then ./$VENV/bin/pip install -e . fi From: Python-list on behalf of Thomas Passin Date: Monday, December 19, 2022 at 11:05 AM To: python-list@python.org Subject: Re: Installation hell *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** On 12/19/2022 9:59 AM, Weatherby,Gerard wrote: > Personally, I don’t use Windows and avoid it like the plague. Python is easy > to install on Linux and Mac. That's not been my experience. Windows installers for Python have worked well for me over many generations of Python releases. It's Linux where I've found difficulties. For example, if your distro's Python install didn't include tkinter (or even pip), how do you get it? It's different for different Linux distros. I generally have to use internet searches to find out. For another example, when you use pip to install a package, it sometimes suggests that you install a newer version of pip itself. Should you do that? On Linux, probably not, because the distro will have modified pip so it puts things in distro-specific places. Yet there is no newer version of pip available through the distro's package manager. Will anything bad happen if you don't update pip? Who knows? I have a Linux VM that has several versions of Python3 on it. Python3.8 came installed with the distro, but for some programs I need Python 3.9+. If I forget which versions I have, how can I find out? People say to use which, but that doesn't work - it only reports "python3". This does work, but it's not all that easy to remember (the grep "site" part is just to filter out uninformative result lines): ~$ find 2>/dev/null ~ -name python -type d |grep "site" /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python Not that this task is much easier to remember on Windows, but it's not harder. One way: the "py" launcher will tell you: py --list -V:3.10 *Python 3.10 (64-bit) -V:3.9 Python 3.9 (64-bit) -V:3.7 Python 3.7 (64-bit) -V:2.7 This is not Linux-bashing, but there's no need for Windows-bashing either. > I’d start here: > https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022 > > From: Python-list on > behalf of Jim Lewis > Date: Sunday, December 18, 2022 at 12:56 PM > To: Python-list@python.org > Subject: Fwd: Installation hell > *** Attention: This is an external email. Use caution responding, opening > attachments or clicking on links. *** > > I'm an occasional user of Python and have a degree in computer science. > Almost every freaking time I use Python, I go through PSH (Python Setup > Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. > Or exe naming confusion: python, python3, phthon311, etc. Or library > compatibility issues - took an hour to find out that pygame does not work > with the current version of python. Then the kludgy PIP app and using a DOS > box under Windows with command prompts which is ridiculous. God only knows > how many novice users of the language (or even intermediate users) were > lost in the setup process. Why not clean the infrastructure up and make a > modern environment or IDE or something better than it is now. Or at least > good error messages that explain exactly what to do. Even getting this > email to the list took numerous steps. > > -- A frustrated user > -- > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZ
Re: Fwd: Installation hell
On 12/19/22 13:34, j via Python-list wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. jan I don't think there was an intent to be dismissive, just to point out that this list, and the tutor list, and other places *do* get questions from people who haven't tried very much, and don't tell their readers what they've tried, jrather ust go "it's broken, please fix it for me". You can call that lazy or not (I personally would not throw out that term); it does happen. The Python installer has a few specific people working on it, most of us here aren't in a position to make changes to it - complaining here can get sympathy, or not, but probably not action. It does seem to work out for a lot of people, so it's always a bit of a surprise when it doesn't. I'd say you ought to file an issue on it if it's broken for you - not to say you haven't tried that already. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. jan On 19/12/2022 17:55, Thomas Passin wrote: On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
RE: Fwd: Installation hell
This type of response is not called for. I thought this list was designed to help people. That's not what this person was doing. Everyone has different experience levels and backgrounds. Help them learn. Don't berate them. Here's what was said: Issues installing python and sending an email? Ask for a refund on your compsci degree. -Original Message- From: Python-list On Behalf Of DFS Sent: Monday, December 19, 2022 12:58 PM To: python-list@python.org Subject: Re: Fwd: Installation hell On 12/18/2022 6:50 AM, Jim Lewis wrote: > I'm an occasional user of Python and have a degree in computer science. > Almost every freaking time I use Python, I go through PSH (Python > Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. > Or exe naming confusion: python, python3, phthon311, etc. Or library > compatibility issues - took an hour to find out that pygame does not > work with the current version of python. Then the kludgy PIP app and > using a DOS box under Windows with command prompts which is > ridiculous. God only knows how many novice users of the language (or > even intermediate users) were lost in the setup process. Why not clean > the infrastructure up and make a modern environment or IDE or > something better than it is now. Or at least good error messages that > explain exactly what to do. Even getting this email to the list took numerous steps. > > -- A frustrated user Issues installing python and sending an email? Ask for a refund on your compsci degree. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/18/2022 6:50 AM, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user Issues installing python and sending an email? Ask for a refund on your compsci degree. -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 2022-12-20 04:15:07 +1100, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 03:56, Peter J. Holzer wrote: > > It is however, quite noticable that almost everyone who asks a question > > about their Python installation on this list is using Windows. I don't > > think this is just because there are more Windows users than Linux or > > Mac Users. > > Yes. I think there are a few reasons for that. One is that there are > many many lazy people in the world, and those people are likely to (a) > use the OS that came with their computers - usually Windows or Mac OS; Yeah. But also on Linux you never have to set up Python. It's just there, ready for use (a few years ago, when Python2 way still the default, you might have had to "apt install python3"[1] but that's it). So the lazy Linux users never run into these problems. > > > I have a Linux VM that has several versions of Python3 on it. Python3.8 > > > came installed with the distro, but for some programs I need Python 3.9+. > > > If I forget which versions I have, how can I find out? > > > > I type python and then ctrl-D. The shell will then show me all commands > > starting with "python" in my path (your shell may have a different key > > combination for that, maybe tab-tab). > > Ah, interesting. When I mentioned tab-tab I was aware that there are > others, but I'm not familiar with Ctrl-D. Normally that means "send > the command as it is", It means that only in cooked mode. Since an interactive shell has to switch the terminal into cbreak or even raw mode anyway, it can mean whatever the the shell wants it to mean. > so I assume your shell is set up to take an unfinished command and > tab-complete it. Which shell is that? zsh (with vi keybindings, although I think ctrl-D works the same with emacs keybindings). > (Also - what happens if you Ctrl-D in the middle of a line? Does that work?) Yes. For example if I type "ls foo", dann move the cursor back after "ls" and type " --co^D", I get: % ls --co foo --color-- control use of color --context -- print any security context of each file If I then type tab, it cycles through the options. If I select --color= and type ^D again, I get % ls --color= foo always autonever Etc. Debian/Ubuntu contains a ton of predefined expansions for zsh. Many of them are very context specific and invoke other commands to figure out the actual options (I guess that it actually invokes ls --help to find the options of help, and for psql it definitely checks which users or databases a local postgres installation has to provide you with sensible options at the appropriate position in the command line. There's also remote filename expansion for scp and rsync, etc.) > > But that works only for Python. Shell expansion works for any command. > > If you use Linux, learn how to use your shell (and maybe learn different > > shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and > > if necessary even sh). > > I agree, although I wouldn't recommend trying to get too much out of > sh as an interactive shell. Yeah. If I happen to login to an account which has /bin/sh as the login shell I'll invoke a different shell if I have to type more than 3 or 4 commands (and there is an alernative installed on the machine, which these days is usually the case). But when I started to use Unix, the Bourne shell was all there was. If you were lucky, there might have been a csh, too, but that didn't use cursor keys either. At least it had a history and you could use ! escapes to access it (I still use those in zsh and bash). hp [1] Or use yum or zypper or whatever, or your GUI package manager if that's your thing. -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On Tue, 20 Dec 2022 at 04:14, Thomas Passin wrote: > > On 12/19/2022 11:36 AM, Chris Angelico wrote: > > On Tue, 20 Dec 2022 at 03:05, Thomas Passin wrote: > >> > >> That's not been my experience. Windows installers for Python have > >> worked well for me over many generations of Python releases. It's Linux > >> where I've found difficulties. For example, if your distro's Python > >> install didn't include tkinter (or even pip), how do you get it? It's > >> different for different Linux distros. I generally have to use internet > >> searches to find out. > > > > If you want to use your distro's Python and add more stuff to it > > globally, then yes, it depends on your distro. This is not really a > > surprise. > > > >> For another example, when you use pip to install a package, it sometimes > >> suggests that you install a newer version of pip itself. Should you do > >> that? On Linux, probably not, because the distro will have modified pip > >> so it puts things in distro-specific places. Yet there is no newer > >> version of pip available through the distro's package manager. Will > >> anything bad happen if you don't update pip? Who knows? > > > > Virtual environments work the same way regardless of distro, including > > allowing you to install an upgraded pip. > > I have always disliked working with venvs and avoid it whenever > possible. But I suppose that's just me. > That's fine. You don't HAVE to use venvs - and in fact, I only use them for a relatively small number of projects (eg those that get deployed to Heroku - make a venv, match Python version to Heroku's offering, and install packages into it, for maximum consistency). There are a few ways to manage things: 1) Always use your package manager. Don't use pip at all. 2) Install pip from your package manager, but then do user installations (~/.local). 3) Install venv from your package manager, use virtual environments everywhere. 4) Build Python from source, parallel to your system Python. 5) Some combination of the above. As you saw from my tab-tab demo, I have a LOT of Pythons installed, many of them alphas and betas. Right now, my 'python3' command is 3.12, but /usr/bin/python3 is the system Python (3.9.2) and has packages managed by apt/dpkg. So when a system-installed script tries to run, it finds the Python and packages that were curated by the Debian folks; but if I, at the command line, type "python3 somescript.py", I get a newer Python with packages managed by pip. Sometimes I'll install those with "sudo python3 -m pip install X", but mostly without sudo, and they land in ~/.local. (Installing as root is useful when I need other users to be able to run the script - it's a pain to try to install something into the correct low-privilege user.) You have options. There's nothing wrong with picking and choosing according to what's convenient for you. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On Tue, 20 Dec 2022 at 03:56, Peter J. Holzer wrote: > > It is however, quite noticable that almost everyone who asks a question > about their Python installation on this list is using Windows. I don't > think this is just because there are more Windows users than Linux or > Mac Users. Yes. I think there are a few reasons for that. One is that there are many many lazy people in the world, and those people are likely to (a) use the OS that came with their computers - usually Windows or Mac OS; and (b) ask a question on a mailing list rather than spend some extra minutes figuring things out with some web searches. An unrelated cause might be a large number of student and/or novice programmers, who simply don't have the groundwork knowledge to figure these things out; and, again, they'll be using whatever OS their systems come with. Why don't we see more Mac questions, then? No idea, and I'm not a Mac person so I can't judge, but I would guess it's just a matter of numbers - Windows outnumbers Mac OS (not counting iOS, which people don't tend to be installing Python on) by a fairly significant factor. > > I have a Linux VM that has several versions of Python3 on it. Python3.8 > > came installed with the distro, but for some programs I need Python 3.9+. > > If I forget which versions I have, how can I find out? > > I type python and then ctrl-D. The shell will then show me all commands > starting with "python" in my path (your shell may have a different key > combination for that, maybe tab-tab). Ah, interesting. When I mentioned tab-tab I was aware that there are others, but I'm not familiar with Ctrl-D. Normally that means "send the command as it is", so I assume your shell is set up to take an unfinished command and tab-complete it. Which shell is that? (Also - what happens if you Ctrl-D in the middle of a line? Does that work?) > But that works only for Python. Shell expansion works for any command. > If you use Linux, learn how to use your shell (and maybe learn different > shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and > if necessary even sh). I agree, although I wouldn't recommend trying to get too much out of sh as an interactive shell. It's best aimed at low-overhead script running, and configured accordingly. Though it's sometimes good to have some familiarity with a low-powered shell and the most basic of input methods, just in case you're ever thrust into a situation where a hard drive has crashed, /bin/bash is corrupted, you don't have convenient access to external boot media, and you just want to get the network interface up so you can do some basic fixes or data recovery... (Never been in precisely that situation, but I have had other key programs unavailable for various reasons, and it's handy to know alternatives!) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 12/19/2022 11:36 AM, Chris Angelico wrote: On Tue, 20 Dec 2022 at 03:05, Thomas Passin wrote: That's not been my experience. Windows installers for Python have worked well for me over many generations of Python releases. It's Linux where I've found difficulties. For example, if your distro's Python install didn't include tkinter (or even pip), how do you get it? It's different for different Linux distros. I generally have to use internet searches to find out. If you want to use your distro's Python and add more stuff to it globally, then yes, it depends on your distro. This is not really a surprise. For another example, when you use pip to install a package, it sometimes suggests that you install a newer version of pip itself. Should you do that? On Linux, probably not, because the distro will have modified pip so it puts things in distro-specific places. Yet there is no newer version of pip available through the distro's package manager. Will anything bad happen if you don't update pip? Who knows? Virtual environments work the same way regardless of distro, including allowing you to install an upgraded pip. I have always disliked working with venvs and avoid it whenever possible. But I suppose that's just me. As long as your distro provides the venv package (on Debian, that's in python3-venv), you can just: $ python3 -m venv env $ source env/bin/activate $ pip install -U pip $ pip install -r requirements.txt $ pip install some-package-name $ etc etc etc etc etc This is also a recommended way to do things on Windows, so you don't even need to do things differently. I have a Linux VM that has several versions of Python3 on it. Python3.8 came installed with the distro, but for some programs I need Python 3.9+. If I forget which versions I have, how can I find out? People say to use which, but that doesn't work - it only reports "python3". This does work, but it's not all that easy to remember (the grep "site" part is just to filter out uninformative result lines): Use what your shell already offers you! If you have multiple Pythons installed, type "python3" and hit tab twice. You should get a list of options. The exact shell you're using will affect how they're shown, but I'm pretty sure most shells (at least, the ones designed to be interactive - /bin/dash might not) will give you some facility like this. Ah, that's nice. Though it didn't report python3.10 on the VM I mentioned earlier. rosuav@sikorsky:~$ python3 python3 python3.5-dbg-config python3.8-config python3.10python3.5dm python3.8m python3.10-config python3.5dm-configpython3.8m-config python3.11python3.5mpython3.9 python3.11-config python3.5m-config python3.9-config python3.12python3.6 python3.9d python3.12-config python3.6-config python3.9-dbg python3.4 python3.6mpython3.9-dbg-config python3.4-config python3.6m-config python3.9d-config python3.4mpython3.7 python3-config python3.4m-config python3.7-config python3d python3.5 python3.7mpython3-dbg python3.5-config python3.7m-config python3-dbg-config python3.5-dbg python3.8 python3d-config rosuav@sikorsky:~$ python3 Yes, this is a bit noisy in that it has the -config and -dbg-config tools listed as well, but you can easily see all the variants that are installed. ~$ find 2>/dev/null ~ -name python -type d |grep "site" /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python Ugh, that's a horribly inefficient way to do it. All you need to do is search $PATH. If tab completion isn't suitable, you could probably use "whereis python3", though it's probably a bit noisy. Sure is! Not that this task is much easier to remember on Windows, but it's not harder. One way: the "py" launcher will tell you: py --list -V:3.10 *Python 3.10 (64-bit) -V:3.9 Python 3.9 (64-bit) -V:3.7 Python 3.7 (64-bit) -V:2.7 This is not Linux-bashing, but there's no need for Windows-bashing either. There's no need for Linux-bashing when Linux isn't the problem. :) And Windows wasn't the OP's problem. Nor was Python. The OP moaned about a lack of IDEs, when pretty much every IDE and text editor out there has Python support. Yes, the OP's rant didn't make much sense to me, especially since it didn't line up with my experience at all. We're not here to bash anything. Well, except maybe the popular Unix shell. I'll /bin/bash that every day of the week... ahem. Anyhow. We're here to share tips and help everyone be more productive. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 2022-12-19 10:55:52 -0500, Thomas Passin wrote: > On 12/19/2022 9:59 AM, Weatherby,Gerard wrote: > > Personally, I don’t use Windows and avoid it like the plague. > > Python is easy to install on Linux and Mac. > > That's not been my experience. Windows installers for Python have worked > well for me over many generations of Python releases. I haven't had any problem either despite being only an occasional Windows user. It is however, quite noticable that almost everyone who asks a question about their Python installation on this list is using Windows. I don't think this is just because there are more Windows users than Linux or Mac Users. > It's Linux where I've found difficulties. For example, if your > distro's Python install didn't include tkinter (or even pip), how do > you get it? It's different for different Linux distros. Yes, but most Linux users don't use a dozen different distributions. And if you've used one for a while you generaLLy know their general naming conventions. So just guessing (with a little help from your shell's expansion mechanism) the name will take you a long way. So as a long-time Debian and Ubuntu user I just know that a Python package foo will be packaged as python3-foo while a Perl package of the same name would be packaged as libfoo-perl. Not exactly consistent, but you get used to it. On RedHat (which I've also used for a long time) the naming conventions are a bit different but also easy to find out. > For another example, when you use pip to install a package, it sometimes > suggests that you install a newer version of pip itself. Should you do that? > On Linux, probably not, because the distro will have modified pip so it puts > things in distro-specific places. Yet there is no newer version of pip > available through the distro's package manager. Will anything bad happen if > you don't update pip? Who knows? If I use pip on Linux I almost always install into a virtual environment (rule 1: Don't mess with the package manager). So year, I can install a new version of pip into that virtual environment without affecting anything else. > I have a Linux VM that has several versions of Python3 on it. Python3.8 > came installed with the distro, but for some programs I need Python 3.9+. > If I forget which versions I have, how can I find out? I type python and then ctrl-D. The shell will then show me all commands starting with "python" in my path (your shell may have a different key combination for that, maybe tab-tab). > People say to use which, but that doesn't work - it only reports > "python3". More specifically it will report *where* the exact command you named is installed. So "which python3" might report /usr/bin/python3 or /usr/local/bin/python3 or maybe /opt/python3.9.2/bin/python3 but it will never report the presence of any executable not named "python3" and even if you have several it will only give you one of them. > ~$ find 2>/dev/null ~ -name python -type d |grep "site" > /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python > /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python > /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python > > Not that this task is much easier to remember on Windows, but it's not > harder. One way: the "py" launcher will tell you: > > py --list > -V:3.10 *Python 3.10 (64-bit) > -V:3.9 Python 3.9 (64-bit) > -V:3.7 Python 3.7 (64-bit) > -V:2.7 But that works only for Python. Shell expansion works for any command. If you use Linux, learn how to use your shell (and maybe learn different shells - I personally prefer zsh, but I can also use bash, ksh, tcsh and if necessary even sh). hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On Tue, 20 Dec 2022 at 03:05, Thomas Passin wrote: > > That's not been my experience. Windows installers for Python have > worked well for me over many generations of Python releases. It's Linux > where I've found difficulties. For example, if your distro's Python > install didn't include tkinter (or even pip), how do you get it? It's > different for different Linux distros. I generally have to use internet > searches to find out. If you want to use your distro's Python and add more stuff to it globally, then yes, it depends on your distro. This is not really a surprise. > For another example, when you use pip to install a package, it sometimes > suggests that you install a newer version of pip itself. Should you do > that? On Linux, probably not, because the distro will have modified pip > so it puts things in distro-specific places. Yet there is no newer > version of pip available through the distro's package manager. Will > anything bad happen if you don't update pip? Who knows? Virtual environments work the same way regardless of distro, including allowing you to install an upgraded pip. As long as your distro provides the venv package (on Debian, that's in python3-venv), you can just: $ python3 -m venv env $ source env/bin/activate $ pip install -U pip $ pip install -r requirements.txt $ pip install some-package-name $ etc etc etc etc etc This is also a recommended way to do things on Windows, so you don't even need to do things differently. > I have a Linux VM that has several versions of Python3 on it. Python3.8 > came installed with the distro, but for some programs I need Python > 3.9+. If I forget which versions I have, how can I find out? People > say to use which, but that doesn't work - it only reports "python3". > This does work, but it's not all that easy to remember (the grep "site" > part is just to filter out uninformative result lines): Use what your shell already offers you! If you have multiple Pythons installed, type "python3" and hit tab twice. You should get a list of options. The exact shell you're using will affect how they're shown, but I'm pretty sure most shells (at least, the ones designed to be interactive - /bin/dash might not) will give you some facility like this. rosuav@sikorsky:~$ python3 python3 python3.5-dbg-config python3.8-config python3.10python3.5dm python3.8m python3.10-config python3.5dm-configpython3.8m-config python3.11python3.5mpython3.9 python3.11-config python3.5m-config python3.9-config python3.12python3.6 python3.9d python3.12-config python3.6-config python3.9-dbg python3.4 python3.6mpython3.9-dbg-config python3.4-config python3.6m-config python3.9d-config python3.4mpython3.7 python3-config python3.4m-config python3.7-config python3d python3.5 python3.7mpython3-dbg python3.5-config python3.7m-config python3-dbg-config python3.5-dbg python3.8 python3d-config rosuav@sikorsky:~$ python3 Yes, this is a bit noisy in that it has the -config and -dbg-config tools listed as well, but you can easily see all the variants that are installed. > ~$ find 2>/dev/null ~ -name python -type d |grep "site" > /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python > /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python > /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python Ugh, that's a horribly inefficient way to do it. All you need to do is search $PATH. If tab completion isn't suitable, you could probably use "whereis python3", though it's probably a bit noisy. > Not that this task is much easier to remember on Windows, but it's not > harder. One way: the "py" launcher will tell you: > > py --list > -V:3.10 *Python 3.10 (64-bit) > -V:3.9 Python 3.9 (64-bit) > -V:3.7 Python 3.7 (64-bit) > -V:2.7 > > This is not Linux-bashing, but there's no need for Windows-bashing either. There's no need for Linux-bashing when Linux isn't the problem. :) And Windows wasn't the OP's problem. Nor was Python. The OP moaned about a lack of IDEs, when pretty much every IDE and text editor out there has Python support. We're not here to bash anything. Well, except maybe the popular Unix shell. I'll /bin/bash that every day of the week... ahem. Anyhow. We're here to share tips and help everyone be more productive. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
On 12/19/2022 9:59 AM, Weatherby,Gerard wrote: Personally, I don’t use Windows and avoid it like the plague. Python is easy to install on Linux and Mac. That's not been my experience. Windows installers for Python have worked well for me over many generations of Python releases. It's Linux where I've found difficulties. For example, if your distro's Python install didn't include tkinter (or even pip), how do you get it? It's different for different Linux distros. I generally have to use internet searches to find out. For another example, when you use pip to install a package, it sometimes suggests that you install a newer version of pip itself. Should you do that? On Linux, probably not, because the distro will have modified pip so it puts things in distro-specific places. Yet there is no newer version of pip available through the distro's package manager. Will anything bad happen if you don't update pip? Who knows? I have a Linux VM that has several versions of Python3 on it. Python3.8 came installed with the distro, but for some programs I need Python 3.9+. If I forget which versions I have, how can I find out? People say to use which, but that doesn't work - it only reports "python3". This does work, but it's not all that easy to remember (the grep "site" part is just to filter out uninformative result lines): ~$ find 2>/dev/null ~ -name python -type d |grep "site" /home/tom/.local/lib/python3.9/site-packages/PyQt5/Qt5/qsci/api/python /home/tom/.local/lib/python3.8/site-packages/pandas/_libs/src/ujson/python /home/tom/.local/lib/python3.10/site-packages/PyQt5/Qt5/qsci/api/python Not that this task is much easier to remember on Windows, but it's not harder. One way: the "py" launcher will tell you: py --list -V:3.10 *Python 3.10 (64-bit) -V:3.9 Python 3.9 (64-bit) -V:3.7 Python 3.7 (64-bit) -V:2.7 This is not Linux-bashing, but there's no need for Windows-bashing either. I’d start here: https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022 From: Python-list on behalf of Jim Lewis Date: Sunday, December 18, 2022 at 12:56 PM To: Python-list@python.org Subject: Fwd: Installation hell *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$> -- https://mail.python.org/mailman/listinfo/python-list
Re: Installation hell
Personally, I don’t use Windows and avoid it like the plague. Python is easy to install on Linux and Mac. I’d start here: https://learn.microsoft.com/en-us/visualstudio/python/overview-of-python-tools-for-visual-studio?view=vs-2022 From: Python-list on behalf of Jim Lewis Date: Sunday, December 18, 2022 at 12:56 PM To: Python-list@python.org Subject: Fwd: Installation hell *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!gdOs-oC1JZcmvMXy1G4irRpzHCUmF565UXVdCjzSWNGZKpmZ04I_llDX4WUeob3asBCjLe6TIthAAhmwFgbph9u1m9A$> -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On Mon, 19 Dec 2022 at 06:10, Mats Wichmann wrote: > Why? Python is a command-line tool to process a language, Similar to > many other languages - Go, for example. Or a C/C++ compiler. *Or* you > can choose to use someone's wrapping of that process inside an > Integrated Development Environment. There are tons that support Python > and let you run your code from within the editor environment without > having to go open a cmd.exe or powershell box. Most of those are > external, but the comes-with-Python IDLE works well, too. I wouldn't bother responding to these sorts of people. They have already decided that it's impossible to find any sort of decent IDE for Python (despite pretty much every editor out there having Python support), are deathly afraid of command lines, and yet feel the need to join a mailing list to tell us all that. You won't convince them of anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/18/22 04:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. It's usually best to wait a bit after a new Python releases, until the myriad packages developed externally which depend on the binary ABI catch up. *Some* carefully follow the beta release cycle and are ready on or close to day 1, some feel like they have enough other work to do and are not. Can understand both viewpoints. You can check - search for something that's important to you on pypi.org and see if binary wheels are available. e.g. https://pypi.org/project/pygame/#files New Python releases are only once a year, so this shouldn't be too huge a burden, Python 3.10 works just fine in the meantime. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. Why? Python is a command-line tool to process a language, Similar to many other languages - Go, for example. Or a C/C++ compiler. *Or* you can choose to use someone's wrapping of that process inside an Integrated Development Environment. There are tons that support Python and let you run your code from within the editor environment without having to go open a cmd.exe or powershell box. Most of those are external, but the comes-with-Python IDLE works well, too. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Installation hell
I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
