View previous topic :: View next topic |
Author |
Message |
picarica Guru
Joined: 11 Aug 2018 Posts: 326
|
Posted: Tue Jun 04, 2024 8:45 am Post subject: ModuleNotFoundError: No module named 'librosa' |
|
|
where can i get librosa plugin? cant found it anywhere in repo, is it supported? or do i have to install it via pip |
|
Back to top |
|
|
rab0171610 Guru
Joined: 24 Dec 2022 Posts: 423
|
Posted: Wed Jun 05, 2024 4:33 am Post subject: |
|
|
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: | # 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:
followed by:
Code: | librosa.show_versions() |
Here is the output:
Code: | 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. |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2421
|
Posted: Wed Jun 05, 2024 5:27 am Post subject: |
|
|
rab0171610 wrote: | 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: | 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 |
|
Back to top |
|
|
eschwartz Developer
Joined: 29 Oct 2023 Posts: 223
|
Posted: Thu Jun 06, 2024 1:59 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22650
|
Posted: Thu Jun 06, 2024 3:24 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
eschwartz Developer
Joined: 29 Oct 2023 Posts: 223
|
Posted: Thu Jun 06, 2024 3:40 pm Post subject: |
|
|
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.) |
|
Back to top |
|
|
|