Can't install modules after pipx

On these last days I installed pipx according to the PEP668. I was able to install only one module (pyslvs… I need it for a blender’s add-on but it won’t install…anyway) and now I can’t install any modules anymore, both with pip and pipx.
Basically, I’m trying to add gimp-stable-diffusion and it won’t works… so, I checked the code and I found that some modules need to be installed (the gimp module, urllib2(but in my system urllib3 is already installed)…) but It seem impossible to install them.
Any solution, please?

Thanks in advance.

You must provide details so that people have a clue what problem tou are seeing.
Share the all the output you see when the install fails as preformatted text.

I need to take again this topic because on these last days I restarted to study a little bit about coding, python and stuff…
My problem remains… after the PEP668, I’m not able to install any new modules anymore. If I get the classic " pip install [module] ", terminal return a message about the need to use pipx according to PEP668…
Otherwise, If I try to install with pipx, terminal returns a message to use pip, either if I try to install from IDE like Thonny, from his own package manager.
If I well understood, pipx is for the installation of scripts in a virtual environment to avoid conflicts with local installations… so , why it won’t recognize the difference between a script and a simple module/library?
How can I avoid this behaviour from Python to have the possibility to install modules again?

Thanks in advance.

Please show the complete message by copying and pasting and formatting it like multi-line code, so that we can see it the way that it appears in your terminal.

[user@hostname ~]$ pip install calendar
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
    python-xyz', where xyz is the package you are trying to
    If you wish to install a non-Arch-packaged Python package,
    create a virtual environment using 'python -m venv path/to/venv'.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.
    If you wish to install a non-Arch packaged Python application,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. Make sure you have python-pipx
    installed via pacman.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Generally, you should use PipX to install applications that are self-contained, and use Pip to install library code that you will use from your own programs.

This message occurs because you are trying to install the package directly into the Python that comes with your system. The Arch maintainers do not want you to do this, because this Python installation is used by scripts that are important to the operating system. If you ever installed some malware this way (maybe because someone hacked PyPI, or hacked the user who maintains a PyPI package), it could damage your entire OS installation instead of just doing whatever damage a user-level Python script could do.

The important part of the error message is the part that tells you to create a virtual environment - as it describes, you want to “install a non-Arch-packaged Python package”. Please follow these steps instead. That will give you something that works like a separate installation of Python, that can the python executable (for Linux, normally this works by making a symlink) but has a separate place to install everything and won’t mess up your system.

You don’t need to type out all the paths every time. Every virtual environment comes with an “activate” script that will temporarily adjust some environment variables (like PATH) so that python means the one in the virtual environment. The virtual environment also gets its own Pip executable that will install into the virtual environment (instead of trying to install to the system Python).

Relevant documentation:

I tried the ‘venv’ method but, probably for my being a beginner, maybe I do something wrong.
As I read, pipx already get a virtual environment for install but I miss something on understanding how it works.
One on my doubt is if I install modules on a virtual environment, what about those are already installed in $PATH that are needed to my scripts that I code?
I miss something on this…

PipX works by making a virtual environment and installing the package into it, yes, but it also tries to set that package up as an application. It’s not very useful if you only want to use the package as library code.

I can’t make much sense of this. You might be confused between the PATH environment variable used by your operating system (it says where to look for programs), and the sys.path value inside Python (it says where to look for Python packages).

You can make any number of virtual environments, and each one has its own set of packages. If you want to develop a new script that uses calendar as well as some other third-party libraries, make a virtual environment and install everything in that environment that your script will need. You can figure out what will be needed as you go. The standard library is always available to you.

Ok, now this point is clear. I was thinking that any python packages was installed in a OS’s environment variable because python use to be pre-installed on GNU/Linux systems.
I will try again as time permit it. Anyway I will “keep a foot” on this thread for future problems.

For now, thanks for your support.

Unfortunately it’s a bit more complicated than that. In the Python world, “package” means two different things, and neither is quite the same as what it means to a system package manager (like Apt, Yum or RPM). They’re all sort of related, but not quite the same.

When you import something in your Python code, this uses a list (an actual Python list, that the interpreter is keeping track of like any other list that you create with your code) of path strings that say where the Python code might be located. The built-in sys module lets you use the name sys.path for that list so that you can examine it. When Python starts up, it will automatically add the needed paths for any third-party libraries that you installed for this Python installation. Every copy of Python gets its own third-party libraries, including virtual environments. Inside the code, “package” just means a module (i.e. something you use with the import statement) that has sub-modules.

Your operating system’s PATH variable does not say anything about where any of these libraries are. Python does still come with most Linux distributions (and Mac), but PATH doesn’t have anything to do with the libraries in your Python code (and never did). Instead, the operating system uses it to find programs (such as Python itself).

When you install third-party libraries, you get a package (the other Python-related meaning) from PyPI (normally), which Pip (typically) sets up in the appropriate folder. It knows which folder to use because it’s relative to the Python executable. Each Python needs its own Pip in order to install third-party libraries for that Python.

Normally, each Python comes with Pip. But when Python comes with your operating system, sometimes it’s specially built without Pip included, as a security feature (so that you don’t add something to that Python that ends up interfering with the Python scripts the operating system depends on - or worse). In these cases, the distro might allow using its package manager to install a package (not the Python sense) to add Pip to the system’s Python. But normally this has nothing to do with how you get Python’s third-party libraries.