pipx fails to install

[iconoclasthero]

$ pipx install grip
Fatal error from pip prevented installation. Full pip output in file:
    /home/$USER/.local/state/pipx/log/cmd_2024-08-18_19.29.59_pip_errors.log

pip seemed to fail to build package:
    docopt>=0.4.0

Some possibly relevant errors from pip install:
    error: subprocess-exited-with-error

Error installing grip.

$ cat /home/$USER/.local/state/pipx/log/cmd_2024-08-18_19.29.59_pip_errors.log
PIP STDOUT
----------
Collecting grip
  Downloading grip-4.6.2-py3-none-any.whl.metadata (961 bytes)
Collecting docopt>=0.4.0 (from grip)
  Downloading docopt-0.6.2.tar.gz (25 kB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'error'

PIP STDERR
----------
  error: subprocess-exited-with-error
  
  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: -11
  ╰─> [0 lines of output]
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully.
│ exit code: -11
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

Python 3.12.5
pipx 1.6.0
pip 24.1.1 from /usr/lib/python3/dist-packages/pip (python 3.12)

Rhino Linux rolling release based on
OS: Rhino Linux 2024.2~RC (server) x86_64
Kernel: Linux 6.10.4-061004-generic
Shell: bash 5.2.21

[iconoclasthero]

Oh I forgot to add, for anyone who hits this error:
apt install python3-docopt
python3-docopt is already the newest version (0.6.2-6).

[kenshanta]

why use pipx instead of just pip itself? just curious

[Disonantemus]

why use pipx instead of just pip itself? just curious

To me, using pipx for CLI tools is better for every python package that is not in repos (Main, Extra, AUR) or not updated, in Arch Linux I get:

$ pip install grip
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
    install.

    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.

Maybe you get something similar in other distros.
With pipx install everything, simple and easy, because venv.

[ernstki]

@iconoclasthero Did you manage to overcome this problem, or just move on to other things?

Perhaps some fiddling with pipx --system-site-packages or pipx inject (to put docopt in the pipx virtualenv manually) will get you farther along?

@joeyespo I'm unable to reproduce this with an up-to-date Rhino Linux 2025.2, Python 3.13.2 and pipx 1.7.1 installed from the default distro package repositories, and Grip 4.6.2 installed with pipx. Perhaps this issue could be closed if the reporter doesn't respond back in a timely manner.

[Disonantemus]

I did move to go-grip, because:

• Is maintained (grip last commit is from 2 years ago).
• Local/offline without API from GitHub.
• Just one small binary to download (or you can compile without been a programmer).

[ernstki]

@Disonantemus Thanks for following up, glad to hear you found a workaround.

Also, sometimes software is just "done." ;)

Acknowledged, grip has some problems currently. It's also true that it's harder to keep a Python program—especially one with multiple third-party dependencies—running forever, because there will be language updates, library deprecations, and API breakages. Not like a static binary that literally will run forever, until we can't run 64-bit Intel code anymore. There are, of course, tradeoffs, like the Go binary for go-grip is 19.3 MB.

I merely want to reinforce the notion that a project without updates in the last two years is not necessary "dead" or non-functional, or unloved by its maintainer. It could just be done!

[iconoclasthero]

@iconoclasthero Did you manage to overcome this problem, or just move on to other things?

Perhaps some fiddling with pipx --system-site-packages or pipx inject (to put docopt in the pipx virtualenv manually) will get you farther along?

@joeyespo I'm unable to reproduce this with an up-to-date Rhino Linux 2025.2, Python 3.13.2 and pipx 1.7.1 installed from the default distro package repositories, and Grip 4.6.2 installed with pipx. Perhaps this issue could be closed if the reporter doesn't respond back in a timely manner.

$ pipx install grip
'grip' already seems to be installed. Not modifying existing installation in '/home/bvargo/.local/share/pipx/venvs/grip'. Pass '--force' to force installation.
$ pipx install --force grip
Installing to existing venv 'grip'
  installed package grip 4.6.2, installed using Python 3.12.9
  These apps are now globally available
    - grip
done! ✨ 🌟 ✨
$ grip .
 * Serving Flask app 'grip.app'
 * Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://localhost:6419
Press CTRL+C to quit
^C * Shutting down...
$ neofetch
Rhino Linux rolling release based on 
OS: Rhino Linux 2025.2 (server) x86_64 
⋮

I passed it to NGINX and was able to access it so it is working now.

why use pipx instead of just pip itself? just curious

To me, using pipx for CLI tools is better for every python package that is not in repos (Main, Extra, AUR) or not updated, in Arch Linux I get:

$ pip install grip
error: externally-managed-environment
⋮
Maybe you get something similar in other distros. With pipx install everything, simple and easy, because venv.

BINGO! (Good to know this happens with Arch too—i.e., it's not just an Ubuntu/Debian thing...)

I believe I also opened a FR with the pipx tool to add a note that if you need additional libraries pipx inject can be used. That's not anywhere in the error for pipx or pip and would be helpful so that it's immediately available for people who either do not know or run across it so infrequently that it's not mentally retained.

[ernstki]

That's not anywhere in the error for pipx or pip and would be helpful so that it's immediately available for people who either do not know or run across it so infrequently that it's not mentally retained.

The whole pipx thing is kind of predicated on an understanding of Python's virtualenvs (specifically the fact that you can pipx inject), which is probably why it took me so long to start using it. I simply hadn't suffered long enough in dependency hell, I guess.

@iconoclasthero It sounds like you worked this out, yes? Would it be OK then to close the issue, or is there still something specific that the maintainer (or another volunteer) could do in terms of documentation?