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

Self-contained Python scripts with uv

blog.dusktreader.dev

Post reply on HN
Print view View original

31–40 of 114 posts

Re: Self-contained Python scripts with uv

#31

Post by stared »

petters wrote: post #22
stared wrote: post #21

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - I…

I completely agree. Hope something like this is eventually standardized. Problem is that uv probably does not want to execute anything to find out dependencies, so it would have to be a very restrictive subset of python syntax. The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies

It can be specified that it is a valid, static structure before imports.

Re: Self-contained Python scripts with uv

#32

Post by shawabawa3 »

ulrischa wrote: post #29

So now I have to make sure uv is installed instead of python. Whar us this better? And python is available on almost any system

The whole point of uv is to solve the nightmare that is running a script with the right version of python with the right dependencies

"Just use the system python" gets you right back to the start (oh no! It didn't parse because it used python 3.11 features and I'm still on 3.5)

Re: Self-contained Python scripts with uv

#33

Post by mr_mitm »

ulrischa wrote: post #29

So now I have to make sure uv is installed instead of python. Whar us this better? And python is available on almost any system

uv can seemlessly get the correct python binary on demand. It would be a pain to get, say, python 3.9 or python 3.14 on my system. Making sure uv is installed actually seems to be less of an issue, but of course this varies.

Re: Self-contained Python scripts with uv

#34

Post by gorgoiler »

hanikesn wrote: post #26
gorgoiler wrote: post #25

Earlier quoted context omitted.

I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: im…

There's justification for that: https://peps.python.org/pep-0723/#why-not-use-possibly-restr...

Thanks for the link.

My counterpoints to the PEP’s arguments are (1) we’re about to run Python so we presumably have a Python parser on hand anyway; and (2) for the foreseeable future it is going to be capable of parsing all previous versions of Python.

It’s a bit fast and loose though. I can see though that it’s helpful for long term stability to have two completely separate languages for dependencies versus the actual code, with the former being far more reduced and conservative than the latter.

If you use Python4.98 triple walrus operators to say requires_version:::=“>=4.98” it would definitely be annoying for any version prior to that to not even be able to parse the requirements, let alone try to meet them.

Re: Self-contained Python scripts with uv

#35

Post by simonw »

gorgoiler wrote: post #25
stared wrote: post #21

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - I…

I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: im…

Because now your code won't run unless you have installed uv previously.

Re: Self-contained Python scripts with uv

#36

Post by nemetroid »

stared wrote: post #31
petters wrote: post #22

Earlier quoted context omitted.

I completely agree. Hope something like this is eventually standardized. Problem is that uv probably does not want to execute anything to find out dependencies, so it would have to be a very restrictive subset of python syntax. The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies

It can be specified that it is a valid, static structure before imports.

Between future statements and other imports, then?

Re: Self-contained Python scripts with uv

#37

Post by falcor84 »

kissgyorgy wrote: post #15

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!

> you don't even need Python to be installed!

Note that this is exactly the case in TFA - uv takes care of installing Python ad-hoc.

Re: Self-contained Python scripts with uv

#39

Post by JimDabell »

stared wrote: post #21

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - I…

That’s fair. I agree with other replies though that parsing and evaluating imperative code is a lot tougher and less flexible than adhering to the principle of least power and making it declarative data.

It’s also worth noting that using comments is exactly how the shebang line works in the first place. It’s just so well-ingrained after 45 years that people don’t notice that it’s a shell comment.

Re: Self-contained Python scripts with uv

#40

Post by nickpsecurity »

gorgoiler wrote: post #25
stared wrote: post #21

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - I…

I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: im…

" In your case that’s uv doing the parsing but another tool might delete it as unused code."

That's probably the goal. It's only there for one tool. If it's not used, we want it to have no impact on the running app. Like comments.

Post reply on HN