Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with uv and PEP 723

cottongeeks.com

Post reply on HN
Print view View original

201–210 of 231 posts

Re: Fun with uv and PEP 723

#201

Post by jcotton42 »

mayli wrote: post #67
js2 wrote: post #47

So far I've only run into one minor ergonomic issue when using `uv run --script` with embedded metadata which is that sometimes I want to test changes to the script via the Python REPL, but that's a bit harder to do since you have to run something like: $ uv run --python=3.13 --with-requirements >> from script import X I'd love if there were something more ergonomic like: $ uv run --with-script script.py python Edit:…

you are welcome cat ~/.local/bin/uve #!/bin/bash temp=$(mktemp) uv export --script $1 --no-hashes > $temp uv run --with-requirements $temp vim $1 unlink $temp

If I may ask, why `unlink` instead of `rm`?

Re: Fun with uv and PEP 723

#202

Post by pxc »

xavdid wrote: post #134
bigstrat2003 wrote: post #21

Earlier quoted context omitted.

> Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. IMO it should stay that way, because any script that needs those things is way past the point where shell is a reasonable choice. Shell scripts should be small, 20 lines or so. The language just plain sucks too much to make it worth using for anything bigger.

My rule of thumb is that as soon as I write a conditional, it's time to upgrade bash to Python/Node/etc. I shouldn't have to search for the nuances of `if` statements every time I need to write them.

What nuances are there to if statements, exactly?

An if statement in, for instance bash, just runs any command and then runs one of two blocks of code based on the exit status of that command. If the exit status is truthy, it runs what follows the `then`. If it's falsey, it rhns what follows the `else`. (`elsif` is admittedly gratuitous syntax— it would be better if it were just implemented as an if inside an else statement.) This seems quite similar to other programming languages and like not very much to remember.

I'll admit that one thing I do in my shell scripts is avoid "fake syntax"— I never use `[` or `[[` because these obscure the real structure of the statements for the sake of cuteness. I just write `test`, which makes clear that it's just an ordinary command, ans also signals to someone who isn't sure what it's doing that they can find out just by running `man test`, `help test`, `info test`, etc., from the same shell.

I also agree that if statements and if expressions should be kept few and simple. But in some ways it's actually easier to do this in shell languages than in many others! Chaining && and/or || can often get you through a substantial script without any if statements at all, let alone nested ones.

Re: Fun with uv and PEP 723

#203

Post by petersellers »

arcanemachiner wrote: post #195
petersellers wrote: post #190

Earlier quoted context omitted.

Or: `uvx ruff` Which one is easier to run, especially for someone who doesn't use python everyday?

The one they definitely won't have to re-learn in a few years.

It's still easier if you use virtual environments so infrequently that you have to look up how to do it every time.

Re: Fun with uv and PEP 723

#204

Post by davidatbu »

puika wrote: post #78

Like the author, I find myself going more for cross-platform Python one-offs and personal scripts for both work and home and ditching Go. I just wish Python typechecking weren't the shitshow it is. Looking forward to ty, pyrefly, etc. to improve the situation a bit

I wouldn't describe Python type checking as a shit-show. pyright is pretty much perfect. One nit against it perhaps is that it doesn't support non-standard typing constructs like mypy does (for Django etc). That's an intentional decision on the maintainer's part. And I'm glad he made that decision because that spurned efforts to make the standard typing constructs more expressive.

I'm also looking forward to the maturity of Rust-based type checkers, but solely because one can almost always benefit from an order of magnitude improvement in speed of type checking, not because Python type-checking is a "shit show".

I do grant you that for outsiders, the fact that the type checker from the Python organization itself is actually a second rate type checker (except for when one uses Django, etc, and then it becomes first-rate) is confusing.

Re: Fun with uv and PEP 723

#205

Post by rednafi »

istjohn wrote: post #200
rednafi wrote: post #142

> Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable. I still do because: - Go gives me a single binary - Dependencies are statically linked - I don’t need any third-party libs in most scenarios - Many of my scripts make network calls, and Go has a better stdlib for HTTP/RPC/Socket work - Better tooling (built-in formatter, no need for pytest, go vet i…

I needed to process a 2 GB xml file the other day. While my Python script was chugging away, I had Claude translate it to Go. The vibe-coded Go program then processed the file before my original Python script terminated. That was the first time I ever touched Go, but it certainly won't be the last.

Go is pretty awesome. I’m sure that spending some time with the script would have made it at least 50 times faster than Python.

Re: Fun with uv and PEP 723

#206

Post by loremm »

Hetzner_OL wrote: post #179
Imustaskforhelp wrote: post #177

Earlier quoted context omitted.

I will say this with a whole heart. My arch linux broke and I wanted to try out nix. The most shocking part about nix is the nix-shell (I know I can use it in other distros but hear me out once), its literally so cool to install projects for one off. Want to record a desktop? Its one of those tasks that for me I do just quite infrequently and I don't like how in arch, I had to update my system with obs as a dependenc…

Hi there, Since you mentioned Hetzner, I thought I would respond here. While we do not have NixOS as one of our standard images for our cloud products, it is part of our ISO library. Customers can install it manually. To do this, create a cloud server, click on it, and then on the "ISO" in the menu, and then look for it listed alphabetically. --Katie

and I've been using nixos on hetzner, nothing crazy but it's always worked great :-). A nice combination with terraform

Re: Fun with uv and PEP 723

#207

Post by loremm »

caspar wrote: post #172
traverseda wrote: post #45

Earlier quoted context omitted.

I don't think nix is that hard for this particular use case. Installing nix on other distros is pretty easy, and once it's installed you just do something like this #! /usr/bin/env nix-shell #! nix-shell -i bash -p imagemagick cowsay # scale image by 50% convert "$1" -scale 50% "$1.s50.jpg" && cowsay "done $1.q50.jpg" Sure all of nixos and packaging for nix is a challenge, but just using it for a shell script is not…

Last time I checked,[0] this works great - as long as you don't particularly care which specific versions of imagemagick or cowsay you want. If you do care, then welcome to learning about niv, flakes, etc. [0]: admittedly 3 years ago or so.

This is a hack but I still found it helpful. If you do want to force a certain version, without worrying about flakes [1] this can be your bash shebang, with similar for nix configuration.nix or nix-shell interactive. It just tells nix to use a specific git hash for it's base instead of whatever your normal channel is.

For my use case, most things I don't mind tracking mainline, but some things I want to fix (chromium is very large, python changes a lot, or some version broke things)

```

#! nix-shell -i bash -p "cowsay" '(import (fetchTarball { url="https://github.com/NixOS/nixpkgs/archive/eb090f7b923b1226e8b..."; sha256 = "15iglsr7h3s435a04313xddah8vds815i9lajcc923s4yl54aj4j";}) {}).python3'

```

[1] flakes really aren't bad either, especially if you think about it as just doing above, but automatically

Re: Fun with uv and PEP 723

#208

Post by mikepurvis »

mr_mitm wrote: post #140
mikepurvis wrote: post #11

Earlier quoted context omitted.

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.

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…

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.

Re: Fun with uv and PEP 723

#209

Post by lenerdenator »

kstrauser wrote: post #130
m2f2 wrote: post #120

Earlier quoted context omitted.

Nice, if only you could count on having it installed on your fleet, and your fleet is 100pct Linux, no AIX, no HPUX, no SOLARIS, no SUSE on IBM Power.... Been there, tried to, got a huge slap in the face.

Been there, done that. I am so glad I don’t have to deal with all that insanity anymore. In the build farm I was responsible for, I was always happy to work on the Linux and BSD boxes. AIX and HPUX made me want to throw things. At least the Itanium junk acted like a normal server, just a painfully slow one. I will never voluntarily run a bunch of non-Linux/BSD servers again.

I honestly don't get why there are still a bunch of non-Linux/BSD servers, at least if the goal is to do UNIX-y stuff.

I haven't touched AIX or HPUX in probably a decade and I thought they were a weird idea back then: proprietary UNIX? Is it still 1993?

Re: Fun with uv and PEP 723

#210

Post by psunavy03 »

x187463 wrote: post #173
bboygravity wrote: post #136

Earlier quoted context omitted.

How did you tell other people/noobs to run your python code (or how did you run it yourself after 5+ years of not touching older projects)?

run script "missing x..." pip install x run script "missing y..." pip install y > y not found google y to find package name pip install ypackage > conflict with other package realize I forgot a venv and have contaminated my system python check pip help output to remember how to uninstall a package clean up system python create venv at cwd start over ...

>realize I forgot a venv and have contaminated my system python

>check pip help output to remember how to uninstall a package

>clean up system python

>create venv at cwd

>start over

This hits disturbingly close to home.

Post reply on HN