pip install scikit-rf
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try
zypper install python313-xyz, where xyz is the package
you are trying to install...
A surf suggested your Tumbleweed system’s Python installation is controlled by the package manager (zypper) rather than pip.
I read this is a safety feature implemented in newer distributions to prevent conflicts between system packages and user-installed packages. The system blocks direct pip installations in this case to protect the system Python environment from potential conflicts or breakage.
I believe you will need to use zypper and not pip to install what you wish to install.
Perhaps others can chime in and give a more precise assessment.
EDIT: If not desired by you to do a system wide install then perhaps a virtual or user level install would work (using appropriate pip flags to do such).
The same message that you gratuitously trimmed also tells you how to install it using several methods, recommended being virtual environment. It even tells you what argument you need to provide to pip to force installing (I would not do it system-wide though, only as user install).
I understand that. I have been anticipating suggestions coming to use pip for packet management. So it felt like a good idea to include its output into my post. That way it should be clear that pip is probably not the right way to go…
As Tw’s packages are managed by zypper I’d rather prefer to use that to get skrf installed. So I included it’s output in my post as well, however zypper does not find any suitable packages for installation of skrf.
Now I’m wondering about what could be the main cause ao the issue. Could it be that Tw’s python packages are simply missing skrf? Or am I missing something else?
It’s not feasible to package everything in PyPI as an RPM. The best approach is what’s suggested by the part of the command you didn’t include in the output - to use Python virtual environments. Then the pip-installed packages don’t conflict with system-installed packages (or mess them up), and things stay separated and managed properly.
Personally, I use that extensively, and it works just fine.
Naturally. My statement was more of a general sort of answer to the question “why isn’t every python module available via RPM?” that I inferred from the discussion, and an explanation as to why using venv is recommended as opposed to trying to get everything under the sun packaged so it’s managed via the platform’s package management system (regardless of platform).
