This seems like a good packaging alternative to containerizing for smaller utilities. Now to convince all my coworkers to install uv..
The showstopper for us is our SCA vulnerability scanner doesn't work with uv yet :(
Self-contained Python scripts with uv
11–20 of 114 posts
Re: Self-contained Python scripts with uv
#12I really like this pattern, but unfortunately I haven't been able to get it to work with my LSP (pyright, in Helix), even when running my editor via uv (`uv run hx script.py`).
I could always do `uv run --with whatever-it-is-i-need hx script.py`, but that's starting to get redundant.
Re: Self-contained Python scripts with uv
#13This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license
uv is licensed under either MIT or Apache-2.0[0]
They can always stop developing or fork to a different license and all future work belongs under that license, but you can't back date licenses, so what exists is guaranteed Open Source. If you're super worried, you can create a fork and just keep it in sync.
But this is essentially true about any other OSS project so I wouldn't be concerned. As far as I'm aware, conda was never open sourced and had always distributed binaries.
[0] https://github.com/astral-sh/uv?tab=readme-ov-file#license
Re: Self-contained Python scripts with uv
#14This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license
I think anaconda's rug pull was on the repository (you can still use packages from conda-forge for free).
uv just uses pypi, so it would be just a question of changing from uv to pip, poetry or whatever, all packages would still be coming from the same place.
Re: Self-contained Python scripts with uv
#15We do the same with Nix, the shebang line looks like this:
#! nix-shell -i python3 -p "python312.withPackages (pkgs: [ pkgs.boto3 pkgs.click ])"
Re: Self-contained Python scripts with uv
#16I really like this pattern, but unfortunately I haven't been able to get it to work with my LSP (pyright, in Helix), even when running my editor via uv (`uv run hx script.py`). I could always do `uv run --with whatever-it-is-i-need hx script.py`, but that's starting to get redundant.
I have my own ugly uve script
$ cat ~/.local/bin/uve
#!/bin/bash
temp=$(mktemp)
uv export --script $1 --no-hashes > $temp
uv run --with-requirements $temp vim $1
unlink $temp
Re: Self-contained Python scripts with uv
#17This seems like a good packaging alternative to containerizing for smaller utilities. Now to convince all my coworkers to install uv..
Uv is amazingly fast. That should help.
Re: Self-contained Python scripts with uv
#18This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license
As I understand it, relicensing is possible when a project has a Contributor Licensing Agreement (CLA) which says that you're signing over your copyright to your contribution to the project's owners. (Who will eventually be bought out by the worst rich person you can think of - Yes, him.) I peeked in uv's contributing guide and issues and didn't see any CLA. In PyTorch the CLA was mentioned at the top of the contribu…
Not having a CLA prevents relicensing but open source licenses aren't revokable anyways.
Re: Self-contained Python scripts with uv
#19We do the same with Nix, the shebang line looks like this: #! nix-shell -i python3 -p "python312.withPackages (pkgs: [ pkgs.boto3 pkgs.click ])" With this, the only requirement is Nix on the system, you don't even need Python to be installed!
Yup, and you can apply the same technique to any language. The obvious example is bash with all the dependencies specified, but I’ve also hacked up quick single file rust scripts using nix shebangs.
Re: Self-contained Python scripts with uv
#20This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license
uv is licensed under either MIT or Apache-2.0[0] They can always stop developing or fork to a different license and all future work belongs under that license, but you can't back date licenses, so what exists is guaranteed Open Source. If you're super worried, you can create a fork and just keep it in sync. But this is essentially true about any other OSS project so I wouldn't be concerned. As far as I'm aware, conda…
Just because something is open source doesn't mean it will be maintained. With uv there is the slight peculiarity that it's written in Rust rather than Python. So you need to count on there being an active group of Rust devs who care about Python.
Because it uses PyPI I'm happy to use it as a package manager and dev tool. The worst that can happen is I have to switch back to pip etc. But I wouldn't use it as package runtime dependency. Use pyinstaller for that.
The use case for this kind of trick I think is developer utility scripts in repos. I wouldn't want to tie any of my personal utils to uv. If it needs dependencies I'll just make a package, which is dead easy now.