Discussion:
No module name mutagen
Add Reply
Tim Johnson
2025-01-01 00:00:10 UTC
Reply
Permalink
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....)

Thanks

Tim
Thomas Passin
2025-01-01 04:12:42 UTC
Reply
Permalink
Post by Tim Johnson
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.
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.
Michael Torrie
2025-01-01 05:41:42 UTC
Reply
Permalink
On Tue, Dec 31, 2024, 17:04 Tim Johnson via Python-list <
Post by Tim Johnson
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
Pip-installed packages that go to /root/.local are only available when you
run Python as root. Your normal user will never pick them up. So I'm not
surprised it's not working.


and indeed, that is the content of
Post by Tim Johnson
/root/.local/share/pipx/shared/lib/python3.12/site-packages/pipx_shared.pth
Could you not apt install python3-mutagen? That will be accessible to all
users.
Peter J. Holzer
2025-01-01 13:16:34 UTC
Reply
Permalink
Post by Tim Johnson
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.
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.
So what changed between the last time it worked and today? Did you
upgrade anything, install anything, delete anything, change permissions,
etc.? Or maybe just invoke your scripts in a different context
(different user, different environment) than before?
Post by Tim Johnson
Mutagen package is
installed at /root/.local/share/pipx/shared/lib/python3.12/site-packages
As Michael already noted, /root is not normally accessible by normal
users. So installing stuff into /root/.local is a bad idea unless you
only ever want to use it as root (which in the case of an audio metadata
library seems unlikely).
Post by Tim Johnson
Must I be using a virtual environment?
I use virtual environments a lot, but that may not be the best option
for you. Especially if you mostly writing command line tools and having
difficulties with upgrades, it might be a good idea to stick with
packages supplied by Ubuntu (I'm guessing that “24.04” above refers to
“Ubuntu 24.04 LTS”). There are over 5000 of them, so it is very likely
that you don't need anything else. This way Ubuntu's package management
will take care of all the dependencies.

Good reasons to use virtual enviroments (on Linux) include:

* You have many different products[1] with different requirements
running on several computers and you want to decouple upgrades of your
products from upgrades to the hosts' OS.
* You need either a package or a specific version not supplied by your
distribution.
* You can't install packages on the target host.

A not so good reason is:

* You are not familiar with your distribution's package manager.

hp

[1] By "product" I mean a collection of software for a common purpose.
That might be a collection of scripts, it might be web site, etc.
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | ***@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Tim Johnson
2025-01-01 18:56:24 UTC
Reply
Permalink
..... Snipped
I resolved this by extrapolating known paths of other non-distro pipx
installs, and am back

in business now. I'm taking lots of notes. For some reason, even after
running updatedb,

I had no luck finding with locate.

I was not aware that mutagen is available through apt. Thanks to you who
brought that up.

I have noted some other things: Running pipx with the verbose flag gives
me more information,

and probably would have been enough to not require me to post this
thread. *And: *the verbose

flag tells me where the logs are. Whoopee!


Seems to me it wouldn't be that hard for pipx to print out the full
install path, both at install runtime and

in the log. Oh well, if I didn't have problems, I would use my
pythonisto brain even less and it

would atrophy even further.


Thanks for all the input. Happy New Year, one and all. :)

Tim

Loading...