[Package]: pipx

[goddaneel]

Why is it worth to add this package?

Install and Run Python Applications in Isolated Environments.
I apologize for the fact that this package can actually be installed by pip, but I think it is necessary to provide a separate system package for this package, similar to python-pip.
The reason is that if you use pip to install it, it creates a lot of unnecessary and confusing cache files, but I installed pipx in order to avoid this kind of confusion.

Home page URL

https://pipx.pypa.io/

Source code URL

https://github.com/pypa/pipx

Packaging policy acknowledgement

• The project is actively developed.

• The project has existing packages and is "well known".

• Licensed under an open source license.

• Not available through a language package manager: pip, npm, cpan, cargo, etc.

• Not taking up too much disk space (< 100MiB per architecture, exceptions can be made)

• Not duplicating the functionality of existing packages.

• Not serving hacking, malware, phishing, spamming, spying, ddos functionality.

• I certify that I have read Termux Packaging Policy and understand that my request will be denied if it is found lacking.

Additional information

No response

[Biswa96]

pipx can be installed with pip install pipx command.

Click here to see the full output of that command

$ pip install pipx
Collecting pipx
  Downloading pipx-1.6.0-py3-none-any.whl.metadata (18 kB)
Collecting argcomplete>=1.9.4 (from pipx)
  Downloading argcomplete-3.5.0-py3-none-any.whl.metadata (16 kB)
Collecting packaging>=20 (from pipx)
  Using cached packaging-24.1-py3-none-any.whl.metadata (3.2 kB)
Collecting platformdirs>=2.1 (from pipx)
  Downloading platformdirs-4.2.2-py3-none-any.whl.metadata (11 kB)
Collecting userpath!=1.9,>=1.6 (from pipx)
  Downloading userpath-1.9.2-py3-none-any.whl.metadata (3.0 kB)
Collecting click (from userpath!=1.9,>=1.6->pipx)
  Downloading click-8.1.7-py3-none-any.whl.metadata (3.0 kB)
Downloading pipx-1.6.0-py3-none-any.whl (77 kB)
Downloading argcomplete-3.5.0-py3-none-any.whl (43 kB)
Using cached packaging-24.1-py3-none-any.whl (53 kB)
Downloading platformdirs-4.2.2-py3-none-any.whl (18 kB)
Downloading userpath-1.9.2-py3-none-any.whl (9.1 kB)
Downloading click-8.1.7-py3-none-any.whl (97 kB)
Installing collected packages: platformdirs, packaging, click, argcomplete, userpath, pipx
Successfully installed argcomplete-3.5.0 click-8.1.7 packaging-24.1 pipx-1.6.0 platformdirs-4.2.2 userpath-1.9.2

[zakuzakukakigori]

Recently, package maintainers have started adopting PEP-668 Externally Managed Environments, which prevents packages from being installed in the interpreter's default (or externally managed) environment and encourages the use of virtual environments.

This feature was introduced starting with pip 23.0, but it is not yet activated in Termux environment, as it is not currently marked as externally managed. However, if we decide to adopt it in the future, it is recommended to also package pipx as documented:

Consider packaging pipx, a tool for installing Python-language applications, and suggesting it in the error. pipx automatically creates a virtual environment for that application alone, which is a much better default for end users who want to install some Python-language software (which isn’t available in the distro) but are not themselves Python users.

Packaging pipx in the distro avoids the irony of instructing users to pip install --user --break-system-packages pipx to avoid breaking system packages. Consider arranging things so your distro’s package / environment for Python for end users (e.g., python3 on Fedora or python3-full on Debian) depends on pipx.

Even though it might be somehow confusing for users who are accustomed to installing packages directly without using virtual environments at first, I believe that PEP-668 provides significant benefits once adopted, given that:

• It is an official solution from Python (upstream) to prevent system package breakage, and has been adopted and tested by other package maintainers, such as:
  • Alpine Linux,
  • Arch Linux,
  • Debian and Ubuntu,
  • Homebrew, among others. (It seems maintainers are heading in that direction, though there are exceptions, e.g. Fedora.)
• Since Termux is single-user, pip install xyz is equivalent to sudo pip install xyz in other Linux environments, which has the potential to break system packages if not done carefully.
• Breaking system packages in a disposable environment, like a Docker container, is not an issue, but Termux environment is not as disposable: It is inconvenient to set everything up from scratch after breaking system packages.

Hi @Biswa96, I understand that adding a package available via the language's package manager might seem unnecessary, but due to the reasons outlined above, I believe pipx's case is different. Could you please reconsider, or perhaps initiate a discussion about PEP-668 in Termux environment?

[zakuzakukakigori]

Actually, I explored the issue for a while with an intention to contribute, but it turned out to be more complex than anticipated. It seems a discussion on how to approach this would be beneficial.

Initially, I marked the default Termux Python installation as externally managed, and this approach worked: pip install began refusing to install packages without a virtual environment, displaying a preconfigured notice.

/data/data/com.termux/files/usr/lib/python3.11/EXTERNALLY-MANAGED

[externally-managed]
Error=To install Python packages system-wide, try `pkg install python-xyz`,
  where xyz is the package you are trying to install.

  If you wish to install a Python library that isn't available in Termux,
  use a virtual environment:

    python -m venv path/to/venv
    source path/to/venv/bin/activate
    pip install xyz

  If you wish to install a Python application that isn't available
  in Termux, it may be easiest to use `pipx install xyz`, which will
  manage a virtual environment for you. You can install pipx with:

    pkg install pipx

  You may restore the old behavior of pip by passing
  the `--break-system-packages` flag to pip, or by adding
  `break-system-packages = true` to your pip.conf file. The latter will
  permanently disable this error.

  If you disable this error, we STRONGLY recommend that you additionally
  pass the `--user` flag to pip, or set `user = true` in your pip.conf
  file. Failure to do this can result in a broken Termux environment.

  Read more about this behavior here: <https://peps.python.org/pep-0668/>

pip install pip (result)

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try `pkg install python-xyz`,
    where xyz is the package you are trying to install.

    If you wish to install a Python library that isn't available in Termux,
    use a virtual environment:

    python -m venv path/to/venv
    source path/to/venv/bin/activate
    pip install xyz

    If you wish to install a Python application that isn't available
    in Termux, it may be easiest to use `pipx install xyz`, which will
    manage a virtual environment for you. You can install pipx with:

    pkg install pipx

    You may restore the old behavior of pip by passing
    the `--break-system-packages` flag to pip, or by adding
    `break-system-packages = true` to your pip.conf file. The latter will
    permanently disable this error.

    If you disable this error, we STRONGLY recommend that you additionally
    pass the `--user` flag to pip, or set `user = true` in your pip.conf
    file. Failure to do this can result in a broken Termux environment.

    Read more about this behavior here: <https://peps.python.org/pep-0668/>

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.

The core functionality of pipx works well, though there is one minor issue: the ability to run different Python versions. Since pipx downloads precompiled Python versions, and no such version exists for Termux. This can be overlooked for now.

However, packaging pipx revealed that it has dependencies, which led me to explore how Termux handles Python packages with dependencies. I discovered that Termux addresses this through a pip install post-install hook, but this could cause issues if the environment is marked as externally managed.

I researched how other package maintainers handle Python dependencies and identified a few potential approaches:

Continue using post-install hooks

By adding the --break-system-packages flag to pip install, we can bypass the restriction and allow the post-install hook to install packages in the default externally managed environment.

Pros:

• Simple implementation with minimal changes to the current architecture.

Cons:

• Contradicts the intent of PEP-668 by allowing package installations in an externally managed environment.
• Installation might be inconsistent, as different versions of dependencies could be installed by pip.

Debian approach: Package dependencies individually

Package each dependency separately. For example, the pipx Debian package depends on python3-argcomplete, python3-packaging, python3-userpath, etc, and those packages may also depend on other packages.

Pros:

• Complies with PEP-668 by keeping all packages externally managed.
• Ensures more consistent installations, as dependencies are handled by us.
• Each package can be reused as a dependency for other packages.

Cons:

• Requires maintenance of more packages, which might be challenging for Termux compared to Debian's larger community.

Homebrew approach: Package dependencies together

Include all dependencies within a single package using a packaged virtual environment, similar to Homebrew's approach with .pth files that refer to the packaged virtual environments for discoverability.

Pros:

• Complies with PEP-668 by keeping all packages externally managed.
• Ensures more consistent installations, as dependencies are handled by us.
• Avoids the need for additional packages to maintain, which might be more suitable for Termux.

Cons:

• Common dependencies may not be easily shared among packages, but this can be addressed by packaging them separately if needed.

Implementing PEP-668 will require careful consideration. I hope this provides a useful starting point. I’m also interested to know whether we might adopt PEP-668 or not with the reasoning behind it. Thank you very much in advance. 🙇‍♂️

[Biswa96]

Recently, package maintainers have started adopting PEP-668 Externally Managed Environments

It is not possible in termux-packages because not all python dependencies are packaged and pulled using pip instead. For reference, see TERMUX_PKG_PYTHON_TARGET_DEPS and TERMUX_PKG_PYTHON_COMMON_DEPS variables in build scripts.