On 12/31/2024 7:00 PM, Tim Johnson via Python-list wrote:
Please let me grumble for a minute : I've been using python since before
1. 5, when I could email Guido van Rossum directly with questions
and on at least one occasion we swapped stories about our cats. I put
six kids though college writing python, and now after
being retired for ten years, I get my butt kicked by python dependencies
every time I upgrade ubuntu. (I'm newly on 24.04) now.
Now, after three weeks on using the following code correctly:
from mutagen import mp3, id3, File as mutaFile
from mutagen.id3 import ID3, TIT2, TPE1
I am as of today, getting an import error for mutagen. Mutagen package
is installed at /root/.local/share/pipx/shared/lib/python3.12/site-packages
and indeed, that is the content of /root/.local/share/pipx/shared/lib/
python3.12/site-packages/pipx_shared.pth
I have added that to my path and am still getting the error. Grrr...
I am at a loss. don't know what to do. I am only using python script for
command line utilities on my desktop and local network.
Must I be using a virtual environment? If so, I would be happy to set
one up if I am given the python-approved directions
(lots of conflicting info out there....)
I go back to Python 1.52 (think I remember the minor version!) also,
though I never emailed Guido.
A different distro of mine in a VM just did an upgrade and changed the
system python from 3.12.x to 3.13.y. Naturally, none of my installed
packages were present in this new system python. I had to reinstall
them all. Maybe this happened to you and you didn't realize. Even if
you had created a venv, I believe you would have had to redo it. It's
very annoying!
One way to avoid this is to install your own, non-system Python. So if
the system python is invoked by python3, yours might be invoked by, say,
python3.12, or even python3.12.3. I've done that on a few VMs.
One advantage of using either your own Python install or a venv is that
it eliminates those warnings that say the system won't allow you to
install something, and then you have to work around it.
The way I use venvs - and I am not expert in them - is to create a
directory to contain my venvs, such as ~/venv. Now let's say you have a
project, call it proj1, that you want to develop or work with in its own
venv. You create it like this:
python3 -m venv ~/venv/proj1
This will create some directories including a site-packages directory,
which will be the location of all packages that you install. The venv
module will install the packages the system's Python already has.
To use the new venv you have to "activate" it, which creates some paths
and variables that cause Python to look first in the venv for modules.
You have to source this script:
source ~/venv/proj1/bin/activate
The activate script will also add "(proj1)" to your terminal's prompt so
you know it's in effect.
Once the venv is activated, which obviously will only be in effect for
that session in that terminal, you install as usual with pip (and pipx
although I don't use pipx so I don't know if there's anything special to
do for a venv):
python3 -m pip install matplotlib # or whatever
Don't use sudo or --user.
You should be able to run pip directly in the venv, but I have developed
the habit of using python3 -m pip because I can be sure I'm running the
right version of pip with the right version of python. It's possible to
end up with a bare "pip" invoked by an unexpected version of Python.
I've been bitten by this before, especially on Windows where I've had
several parallel Python installations.
--
https://mail.python.org/mailman/listinfo/python-list
