ModuleNotFoundError: No module named 'librosa'

[picarica]

where can i get librosa plugin? cant found it anywhere in repo, is it supported? or do i have to install it via pip

[rab0171610]

You would need to install it with pip. I am not sure how others here handle python stuff that are not available through portage. The recommended method is installing to a virtual environment (venv) but I usually use the brute force method for obscure modules by using --break-system-packages. I have not had issues but others here will probably have a strong opinion about it one way or another. You will have to wait for someone else to explain what the current best practice for that is on Gentoo.

If you were wanting to do it the proper way (ebuild), I modified an existing ebuild in my localrepo for a python package. After converting it for librosa, it appears to have installed correctly.

If you have or set up a local repository for ebuilds, this worked for me using a recent version of librosa:

dev-python/librosa/librosa-0.10.2.ebuild

Code: Select all

# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

PYTHON_COMPAT=( python3_{10..12} )
inherit distutils-r1

DESCRIPTION="A python package for music and audio analysis."
HOMEPAGE="https://github.com/librosa/librosa"

LICENSE="GPL-3+"
SLOT="0"

if [[ "${PV}" == *9999* ]]; then
	inherit git-r3
	EGIT_REPO_URI="https://github.com/librosa/librosa.git"
else
	SRC_URI="https://github.com/librosa/librosa/archive/refs/tags/${PV}.tar.gz -> ${P}.tar.gz"
	KEYWORDS="amd64"
	S="${WORKDIR}/${PN}-${PV}"
fi

RESTRICT="mirror"
IUSE=""
# pytest-xdist isn't really required but it helps speed up tests
BDEPEND="
	dev-python/orjson[${PYTHON_USEDEP}]
"

RDEPEND="
	${BDEPEND}
"

distutils_enable_tests pytest

src_prepare() {
	distutils-r1_python_prepare_all

}

python_test() {
	epytest -n auto
}

Someone else would have to improve upon this as it may also need dev-python/lazy-loader and possibly dev-python/numpy and dev-python/matplotlib as dependencies. Maybe there are others.

When opening up a python console, I typed:

Code: Select all

import librosa

followed by:

Code: Select all

librosa.show_versions()

Here is the output:

Code: Select all

INSTALLED VERSIONS
------------------
python: 3.12.3 (main, May 21 2024, 03:35:07) [GCC 13.2.1 20240113]

librosa: 0.10.2

audioread: None
numpy: 1.26.4
scipy: None
sklearn: None
joblib: None
decorator: None
numba: None
soundfile: None
pooch: None
soxr: None
typing_extensions: None
lazy_loader: 0.4
msgpack: None

numpydoc: None
sphinx: None
sphinx_rtd_theme: None
matplotlib: None
sphinx_multiversion: None
sphinx_gallery: None
mir_eval: None
ipython: None
sphinxcontrib.rsvgconverter: None
pytest: None
pytest_mpl: None
pytest_cov: None
samplerate: None
resampy: None
presets: None
packaging: 24.0

I don't know which of those you would need to also install for your use case.

[logrusx]

You would need to install it with pip. I am not sure how others here handle python stuff that are not available through portage. The recommended method is installing to a virtual environment (venv) but I usually use the brute force method for obscure modules by using --break-system-packages. I have not had issues but others here will probably have a strong opinion about it one way or another. You will have to wait for someone else to explain what the current best practice for that is on Gentoo.

Code: Select all

 pip install --help

...

  --user                      Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%\Python on Windows. (See the Python documentation for site.USER_BASE for full
                              details.)

You just need to be careful which use you do that for. It's not a good idea to do it for root. This is kind of environment pollution if you're not careful with it.

Best Regards,
Georgi

[eschwartz]

pip install automatically implies --user if you run it as non-root, so the issue rarely comes up because nothing suggests that you should use "sudo pip".

(Do not ever use "sudo pip".)

That being said, the pip functionality of break-system-packages is broken and buggy by design. You need that flag even to install with --user despite that being user packages, not system packages.

You can add that option to a pip.conf configuration file so you don't need to type it in every time, though.

[Hu]

As I understand it, the Python rules for search paths mean that using pip install --user will affect the results of import lib run by that user, even when that import lib is from a system library. Thus, if you pip install --user portage==broken-version, then equery as your user will find the broken-version of portage and fail when it tries to use Portage libraries to support its query. As such, there is some value to preventing users from unknowingly installing packages into their account-level search path.

[eschwartz]

This is a trivially solvable problem and I have discussed it a few times with Sam/mgorny and griped a bit with upstream CPython as well.

From the Gentoo perspective, the way Gentoo packages pip and CPython to make pip behave this was was intended *solely* to prevent pip from overwriting portage managed files in /usr, and its effect on pip install --user is an unintended side effect as users are "allowed" to break their user install as long as portage run as root doesn't have issues.

It replaced a former downstream Gentoo-specific patch to pip itself that made pip error out when it detected it was run with the root UID, on the theory that using an upstream option even if it sucks and has bad side effects is better than maintaining patches.


I've now been waiting since November for an upstream PyPA project to merge patches which I need so I can improve Gentoo's gpep517 and solve this better.

(Unfortunately that involves getting PyPA to merge patches! Hence the wait times.)