Any plans to support packaged binary?

[sdbds]

Thanks for your work, UV always great!

Recently I realized that it is convenient to package the project into an exe so that users can install all environments and third-party dependencies, like pyinstall, auto-py-to-exe.

I guess UV seems to do the same thing, since it can lock python versions, dependency versions, etc.

[ceejatec]

My experience, for what it's worth: I support a few Python-based utilities in our company, and used PyInstaller to create standalone distributable binaries. I've recently converted one such project to uv, by re-organizing it to be deployable via PyPI and then writing a wrapper script (or a wrapper Go program, for Windows) that silently installs uv (if necessary) and then runs uv tool install <mytool> before passing all the input arguments to the real binary. This means the user experience is unchanged - they can still download a tool with the same name, and run it with the same arguments, and be more or less oblivious to the fact that I'm dumping uv and a python version into ~/.local.

Neither solution - PyInstaller, or uv-plus-wrapper-scripts - is entirely perfect, but so far I think I'm happier with the latter. PyInstaller is tricky to get right, especially cross-platform. And the user experience with PyInstaller is hit-or-miss; on Windows and Mac it's often painfully slow to start up, and since it's basically a self-extracting binary it has a habit of setting off anti-virus software and the like. The uv-plus-wrapper-script solution is generally much faster and much easier to get right, and so far at least I haven't seen it causing any real problems, but it does burn rather a lot more of the user's disk space.

The wrapper solution I came up with would be trivially adaptable to any other PyPI-distributed package, and even to non-PyPI packages with a little work. You can take a look here if you like. Note that the uv bug I mentioned has actually just been fixed, so I can remove that workaround.

If any of the uv authors are reading this, I do have a dream: it would be awesome if the uv binary itself could identify that it was invoked with a name other than uv, and fall over to behaving as if it was invoked with uv tool run <name> (I believe similarly to how uvx used to work, before it was split into a separate executable). That would let people distribute uv itself as a fully-featured wrapper around any PyPI-distributed tool. In fact, I'm going to take a run at proposing a change like that, although I'm definitely a Rust neophyte so I'm not sure how well I can do it.

[sdbds]

My experience, for what it's worth: I support a few Python-based utilities in our company, and used PyInstaller to create standalone distributable binaries. I've recently converted one such project to uv, by re-organizing it to be deployable via PyPI and then writing a wrapper script (or a wrapper Go program, for Windows) that silently installs uv (if necessary) and then runs uv tool install <mytool> before passing all the input arguments to the real binary. This means the user experience is unchanged - they can still download a tool with the same name, and run it with the same arguments, and be more or less oblivious to the fact that I'm dumping uv and a python version into ~/.local.

Neither solution - PyInstaller, or uv-plus-wrapper-scripts - is entirely perfect, but so far I think I'm happier with the latter. PyInstaller is tricky to get right, especially cross-platform. And the user experience with PyInstaller is hit-or-miss; on Windows and Mac it's often painfully slow to start up, and since it's basically a self-extracting binary it has a habit of setting off anti-virus software and the like. The uv-plus-wrapper-script solution is generally much faster and much easier to get right, and so far at least I haven't seen it causing any real problems, but it does burn rather a lot more of the user's disk space.

The wrapper solution I came up with would be trivially adaptable to any other PyPI-distributed package, and even to non-PyPI packages with a little work. You can take a look here if you like. Note that the uv bug I mentioned has actually just been fixed, so I can remove that workaround.

If any of the uv authors are reading this, I do have a dream: it would be awesome if the uv binary itself could identify that it was invoked with a name other than uv, and fall over to behaving as if it was invoked with uv tool run <name> (I believe similarly to how uvx used to work, before it was split into a separate executable). That would let people distribute uv itself as a fully-featured wrapper around any PyPI-distributed tool. In fact, I'm going to take a run at proposing a change like that, although I'm definitely a Rust neophyte so I'm not sure how well I can do it.

Thanks for sharing, I will check this method out.

I only know python and java, not rust at all, otherwise I would like to provide more help.

[zanieb]

Support for this feature is being tracked in #5802

[zanieb]

If any of the uv authors are reading this, I do have a dream: it would be awesome if the uv binary itself could identify that it was invoked with a name other than uv, and fall over to behaving as if it was invoked with uv tool run (I believe similarly to how uvx used to work, before it was split into a separate executable). That would let people distribute uv itself as a fully-featured wrapper around any PyPI-distributed tool. In fact, I'm going to take a run at proposing a change like that, although I'm definitely a Rust neophyte so I'm not sure how well I can do it.

Interesting! I'd recommend opening a dedicated issue for this feature.

[sdbds]

Support for this feature is being tracked in #5802正在跟踪对此功能的支持 #5802

Thanks, I will keep an eye on this feature.

[ceejatec]

Interesting! I'd recommend opening a dedicated issue for this feature.

Thanks, I went ahead and did so: #10465

Get a cup of coffee... brevity is definitely not one of my strengths.