Live data from Hacker News

Self-contained Python scripts with uv

blog.dusktreader.dev

101–110 of 114 posts

Re: Self-contained Python scripts with uv

#101
post #98

Earlier quoted context omitted.

Right, you need to have uv installed, and if you don't, you'll probably have to install it manually or through `curl | sh`. I think this is a valid complaint. Something to consider is that it will become less of an issue as package managers include uv in their repositories. For example, uv is already available in Alpine Linux and Homebrew: https://repology.org/project/uv/versions . Another thing is that inline script…

curl | sh is an abhorrent practice and should never be used.

The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.

Re: Self-contained Python scripts with uv

#103
post #98

Earlier quoted context omitted.

Right, you need to have uv installed, and if you don't, you'll probably have to install it manually or through `curl | sh`. I think this is a valid complaint. Something to consider is that it will become less of an issue as package managers include uv in their repositories. For example, uv is already available in Alpine Linux and Homebrew: https://repology.org/project/uv/versions . Another thing is that inline script…

curl | sh is an abhorrent practice and should never be used.

It's often both useful and appropriate in Dockerfiles.

Re: Self-contained Python scripts with uv

#104
post #27

We 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!

How to do the same thing with `nix shell` (The flake based command) instead of `nix-shell`?

it is a bit more annoying: https://nix.dev/manual/nix/2.22/command-ref/new-cli/nix3-she...

Re: Self-contained Python scripts with uv

#105
post #98

Earlier quoted context omitted.

curl | sh is an abhorrent practice and should never be used.

The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.

Why do you use 10 different distros that only get updated once in a blue moon?

Re: Self-contained Python scripts with uv

#107
As mentioned in other comments, the "self-contained" claim depends on `uv` being installed.

For those who want a really self-contained Python script, I'd like to point out the Nuitka compiler [0]. I've been using it in production for my gRPC services with no issues whatsoever - just "nuitka --onefile run.py" and that's it. It Just Werks. And since it's a compiler, the resulting binary is even faster than the original Python program would be if it were bundled via Pyinstaller.

The author's GitHub page [1] contains the following text:

    Other than software development, my passion would be no
    other. It's my life mission to create the best Python
    Compiler I can possibly do or die trying, ... of old
    age.
[0] https://nuitka.net/

[1] https://github.com/kayhayen

Re: Self-contained Python scripts with uv

#108
post #105

Earlier quoted context omitted.

The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.

Why do you use 10 different distros that only get updated once in a blue moon?

I am not using 10 different OSs/distors, but across every potential user of my tool, it could very easily be 10+.

Re: Self-contained Python scripts with uv

#109
post #98

Earlier quoted context omitted.

curl | sh is an abhorrent practice and should never be used.

The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.

No, the alternative is to package it yourself and offer it with a signing key. If you make a .deb and .rpm, you’ve covered a large majority of end users.

Re: Self-contained Python scripts with uv

#110

Earlier quoted context omitted.

The alternative is to wait for the 10 different distros to all package your program and then update it once every blue moon.

No, the alternative is to package it yourself and offer it with a signing key. If you make a .deb and .rpm, you’ve covered a large majority of end users.

That sounds worse than the status quo, a lot of developers use Arch Linux, NixOS, other uncommon (to non-devs) distros.

Why is signing key with .deb/.rpm better than `curl | sh` from a HTTPS link on a domain owned by the author? .deb/.rpm also contain arbitrary shell commands.

Post reply on HN