CLI autocomplete is painfully slow

[skyf0l]

Running exegol with argcomplete enabled feels sluggish, every Tab press freezes for ~0.5–1s before suggestions appear.

Expected: Completion should return almost instantly (tens of milliseconds), only touching the minimal modules needed to list containers/images.

Actual: Completion blocks for hundreds of ms, re-importing heavy modules and even contacting Docker/Supabase during completion.

Impact: Everyday CLI use feels laggy; shells look frozen; tab completion becomes unusable on slower machines.

Notes: Profiling shows most time spent importing ExegolController, ExegolManager, UserConfig, SessionHandler, and calling DockerUtils in the completer. We should avoid importing the full CLI stack for completion and cache container/image names without hitting Docker on every Tab.

[lap1nou]

Greetings,

I also remarked this does the same thing with exh and nxc, this might not be a problem for the Exegol wrapper only.

[skyf0l]

Yup, it's kinda annoying when you need to work quickly...

[lap1nou]

I think I found the cause from a post on this subreddit: https://www.reddit.com/r/learnpython/comments/freip8/comment/flvw3ys/

Apparently, doing all the import after the call to argcomplete.autocomplete() greatly reduce the input delay, I tried this with exh and I think this make a notable difference, we may also make use of recent lazy loading feature from Python in the future (https://peps.python.org/pep-0810/).

[tristanqtn]

Opened #313 to address this.

Approach:

• The parser is now built and handed to argcomplete before the heavy imports run, so a completion request never loads docker, git, supabase, pydantic, cryptography, jwt or requests. @lap1nou this is essentially your suggestion, deferring imports past argcomplete.autocomplete(), adapted to the fact that constructing the parser is itself what pulled most of them in, via ExegolParameters → ExegolManager and UserConfig → SessionHandler.
• Container names are cached in ~/.exegol/.datacache, next to the existing image cache, so the completer no longer contacts the Docker daemon on every Tab. The cache is refreshed on container listing and kept in sync on create / remove / rename.

Measured against dev on a real host: 1015 ms → 270 ms per Tab (3.8x). The completion path drops from 52 wrapper modules + 17 heavy third-party packages to 19 + 0.

Two related problems surfaced while working on it and are fixed in the same PR:

• Completion died outright when Docker was unavailable. DockerUtils failures reach logger.critical(), which calls exit(1) inside the completer, and SystemExit isn't caught by except Exception, so a stopped or permission-denied daemon silently killed the completion process instead of returning no suggestions.
• There was no way to install the completion in a shell. PYTHON_ARGCOMPLETE_OK was only in exegol.py, not in the module backing the console script, so global completion couldn't detect the installed binary either. exegol completion [bash|zsh|fish|tcsh|powershell] now generates the script in-process, which also covers pipx/uv installs where register-python-argcomplete isn't on PATH.

The residual ~150-250 ms is rich + yaml + ifaddr at import time. Going below that would mean decoupling ExeLog from rich, which I left out of scope.