Fun with uv and PEP 723

I know there are real reasons for slow Python startup time, with every new import having to examine swaths of filesystem paths to resolve itself, but it really is a noticeable breath of fresh air working with tools implemented in Go or Rust that have sub-ms startup.

The Python startup latency thing makes sense, but I really don't understand why it would take `pyenv` a long time to print each line of its "usage" output (the one that appears when invoking it with `--help`) once it's already clearly in the code branch that does only that.

It feels like like it's doing heavy work between each line printed! I don't know any other cli tool doing that either.

The "slowness" and the utter insanity of trying to make a "works on my computer" Python program work on another computer pushed me to just rewrite all my Python stuff in Go.

About 95% of my Python utilities are now Go binaries cross-compiled to whatever env they're running in. The few remaining ones use (API) libraries that aren't available for Go or aren't mature enough for me to trust them yet.

Not to derail the Python speed hate train but pyenv is written in bash.

It's a tool for installing different versions of Python, it would be weird for it to assume it already had one available.

There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.

Oh, that might actually explain the slow line printing speed. Thank you, solves a long standing low stakes mystery for me :)

You don't have to import everything just to print the help. I try to avoid top-level imports until after the CLI arguments have been parsed, so the only import until then is `argparse` or `click`. This way, startup appears to be instant even in Python.

Example:

    if __name__ == "__main__":
        from myapp.cli import parse_args

        args = parse_args()

        # The program will exit here if `-h` is given

        # Now do the heavy imports

        from myapp.lib import run_app

        run_app(args)

Another pattern, though, is that a top level tool uses pkg_resources and entry_points to move its core functionality out to verb plugins— in that case the help is actually the worst case scenario because not only do we have to scan the filesystem looking for what plugins are available, they all have to be imported in order to ask each for its help strings.

An extreme version of this is the colcon build tool for ROS 2 workspaces:

https://github.com/colcon/colcon-core/blob/master/setup.cfg#...

Unsurprisingly, startup time for this is not great.