3 ms·

uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Pytho

uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Python scripts from Github super easily. No git clone, no venv creation + entry + pip install. And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than pip. It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheless.

lxgr 1y ago
Truly. uv somehow resolves and installs dependencies more quickly than pyenv manages to print its own --help output.
- mikepurvis 1y ago
  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.
  - lxgr 1y ago
    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.
    - heavyset_go 1y ago
      There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.
  - theshrike79 1y ago
    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.
  - Spivak 1y ago
    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.
    - lxgr 1y ago
      Oh, that might actually explain the slow line printing speed. Thank you, solves a long standing low stakes mystery for me :)
  - mr_mitm 1y ago
    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)
    - mikepurvis 1y ago
      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#L87 https://github.com/colcon/colcon-core/blob/master/setup.cfg#... Unsurprisingly, startup time for this is not great.
- heavyset_go 1y ago
  Last time I looked, pyenv contributors were considering implementing a compiled launcher for that reason. But that ship has sailed for me and I'm a uv convert.
TZVdosOWs3kZHus 1y ago
No more dependency problems with mkdocs I ran into before every other month: uvx --with mkdocs-material --with mkdocs-material-extensions --with mkdocs-nav-weight mkdocs serve -a localhost:1337 Funnily enough it also feels like it is starting faster.
- winterqt 1y ago
  Is there a reason you didn’t explicitly pull in mkdocs as a dependency in that invocation? I guess uv will expose it/let you run it anyways due to the fact that it’s required by everything else you did specify.
  - tfitz237 1y ago
    its a `uvx` call, so the tool being invoked is `mkdocs`, and all the other dependencies are additions on top of that
mmcnl 1y ago
I agree uv is amazing, but it's not a virtual machine, it's a virtual environment. It runs the scripts on top of your OS without any hardware virtualization. The virtual environment only isolates the Python dependencies.
bjornasm 1y ago
>It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheles Thought I was the only one thinking this. Got to open an issue, I think it would be nice to have some more examples showcasing different use cases.
nebben64 1y ago
not sure if OP will see this, but how does uv or uvx forgo `git clone` ? You still need to clone whatever you're trying to run, or am I missing something.

lxgr 1y ago

Truly. uv somehow resolves and installs dependencies more quickly than pyenv manages to print its own --help output.

mikepurvis 1y ago
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.
- lxgr 1y ago
  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.
  - heavyset_go 1y ago
    There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.
- theshrike79 1y ago
  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.
- Spivak 1y ago
  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.
  - lxgr 1y ago
    Oh, that might actually explain the slow line printing speed. Thank you, solves a long standing low stakes mystery for me :)
- mr_mitm 1y ago
  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)
  - mikepurvis 1y ago
    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#L87 https://github.com/colcon/colcon-core/blob/master/setup.cfg#... Unsurprisingly, startup time for this is not great.
heavyset_go 1y ago
Last time I looked, pyenv contributors were considering implementing a compiled launcher for that reason. But that ship has sailed for me and I'm a uv convert.

TZVdosOWs3kZHus 1y ago

No more dependency problems with mkdocs I ran into before every other month: uvx --with mkdocs-material --with mkdocs-material-extensions --with mkdocs-nav-weight mkdocs serve -a localhost:1337 Funnily enough it also feels like it is starting faster.

winterqt 1y ago
Is there a reason you didn’t explicitly pull in mkdocs as a dependency in that invocation? I guess uv will expose it/let you run it anyways due to the fact that it’s required by everything else you did specify.
- tfitz237 1y ago
  its a `uvx` call, so the tool being invoked is `mkdocs`, and all the other dependencies are additions on top of that

mmcnl 1y ago

I agree uv is amazing, but it's not a virtual machine, it's a virtual environment. It runs the scripts on top of your OS without any hardware virtualization. The virtual environment only isolates the Python dependencies.

bjornasm 1y ago

>It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheles Thought I was the only one thinking this. Got to open an issue, I think it would be nice to have some more examples showcasing different use cases.

nebben64 1y ago

not sure if OP will see this, but how does uv or uvx forgo `git clone` ? You still need to clone whatever you're trying to run, or am I missing something.