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

181–190 of 231 posts

Re: Fun with uv and PEP 723

#181

Post by Imustaskforhelp »

altbdoor wrote: post #178
Imustaskforhelp wrote: post #176

I have a lot of opinions about this. Firstly, I have been a HN viewer for so many time and this is the one thing about pep python scripts THAT always get to the top of leaderboard of hackernews by each person discovering it themselves. I don't mean to discredit the author. His work was simple and clear to understand. I am just sharing this thesis that I have that if someone wants karma on Hackernews for whatever reas…

One can use uv to add into the dependencies list $ touch foo.py $ uv add --script foo.py requests Updated `foo.py` $ cat foo.py # /// script # requires-python = ">=3.13" # dependencies = [ # "requests", # ] # ///

Thanks a lot friend, But one of the issues with this is that I need to know about requests and sometimes their names can be different and I actually had created a cli tool called uvman which actually wanted to automate that part too.

But my tool was really finnicky and I guess it was built by AI ,so um yea, I guess you all can try it, its on pypi. I think that it has a lot of niche cases where it doesn't work. Maybe someone can modify it to make it better as I had built it like 3-4 months ago if I remember correctly and I have completely forgotten how things worked in uv.

Re: Fun with uv and PEP 723

#182

Post by tfitz237 »

winterqt wrote: post #175
TZVdosOWs3kZHus wrote: post #143

Earlier quoted context omitted.

No more dependency problems with mkdocs I ran into before every other month: uvx --with mkdocs-material --with mkdocs-material-extensions --with mkdocs-nav-weight mkdocs serve -a localhost:1337 Funnily enough it also feels like it is starting faster.

Is there a reason you didn’t explicitly pull in mkdocs as a dependency in that invocation? I guess uv will expose it/let you run it anyways due to the fact that it’s required by everything else you did specify.

its a `uvx` call, so the tool being invoked is `mkdocs`, and all the other dependencies are additions on top of that

Re: Fun with uv and PEP 723

#183

Post by hnfong »

kibwen wrote: post #85
indosauros wrote: post #54

Earlier quoted context omitted.

What's going on is "we have 14 standards so we need to create a 15th" actually worked this time

It works far more of the time than people give it credit for. There are a lot of good XKCDs, but that one is by far the worst one ever made, as far as being a damaging meme goes.

It's survival bias. You'd never see the confusion from would-have-failed standards-wannabes that xkcd927 helped prevent.

Re: Fun with uv and PEP 723

#184

Post by Hetzner_OL »

Imustaskforhelp wrote: post #180
Hetzner_OL wrote: post #179

Earlier quoted context omitted.

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

Hey hetzner. I am just a 16 year old boy (technically I am turning 17 on 2nd july haha but I want nothing from ya haha) who has heard great things about your service while being affordable but never have tried them because I guess I just don't have a credit card/I guess I am a really frugal person at this moment haha. I was just reading one of your own documents if I feel correct and it said that the support isn't th…

Hi again, I'm happy that I made your day! You seem pretty easy to please if that is all it takes. Keep in mind that customers must be 18 years old. I believe that is a legal requirement here in Germany, where we are based. Until then, if you're a fan, maybe you'd enjoy seeing what we're up to. We're on YouTube, reddit, Mastodon, Instagram, Facebook, and X. --Katie

Re: Fun with uv and PEP 723

#185

Post by linsomniac »

4dregress wrote: post #128

I’ve been a python dev for nearly a decade and never once thought dep management was a problem. If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell . So I still don’t see what the fuss is about? I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI…

I've been a python dev for nearly 3 decades and feel that uv is removing a lot of the rough edges around dependency management. So maybe "problem" is the wrong word; I've been able to solve dependency management issues usually without too much trouble, I have also spent a significant amount of time dealing with them. For close to a decade I was managing other peoples Python environments on production systems, and that was a big mess, especially with trying to ensure that they stayed updated and secure.

If you don't see what the fuss is about, I'm happy for you. Sounds like you're living in a fairly isolated environment. But I can assure you that uv is worth a lot of fussing about, it's making a lot of our lives a lot easier.

Re: Fun with uv and PEP 723

#186

Post by arcanemachiner »

yard2010 wrote: post #138
ACAVJW4H wrote: post #12

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended ti…

That's a shame as I got to a monk-level python jujitsu. I can fix any problem, you name it, https nightmare, brew version vs pyenv, virtualenv shenanigans. Now all this knowledge is a bad investment of time.

Never say never.

Knowing the Python packaging ecosystem, uv could very well be replaced by something else. It feels different this time, but we won't know for a while yet.

Re: Fun with uv and PEP 723

#187

Post by arcanemachiner »

petersellers wrote: post #133
4dregress wrote: post #128

I’ve been a python dev for nearly a decade and never once thought dep management was a problem. If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell . So I still don’t see what the fuss is about? I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI…

> it’s always been done in that ENVs python shell . What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.

Create a virtual environment:

python3 -m venv venv

Activate the virtual environment:

source venv/bin/activate

Deactivate the virtual environment:

deactivate

Re: Fun with uv and PEP 723

#188

Post by SAI_Peregrinus »

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 ...

Thankfully some newer systems will error by default if you try to mess with them via pip instead of your system's package manager. Easy to override if you want to, and saves a lot of effort fixing accidental screw ups.

Re: Fun with uv and PEP 723

#189

Post by furyofantares »

avianlyric wrote: post #139
furyofantares wrote: post #101

Earlier quoted context omitted.

Same, although I think it doesn't support my idiosyncratic workflow. I have the same files sync'd (via dropbox at the moment) on all my computers, macos and windows and wsl alike, and I just treat every computer likes it's the same computer. I thought this might be a recipe for disaster when I started doing it years ago but I have never had problems. Some stuff like npm or dotnet do need an npm update / dotnet restor…

You should probably look to have the uv managed venvs completely excluded from being synced, and forcing every machine to build its own venv. Given how fast and consistent uv is, there’s no real reason to share the actual venvs between machines anymore.

Thank you! I wrap all my tools in very simple shell+batch scripts anyway so just specifying a different venv for each does the trick.

Re: Fun with uv and PEP 723

#190

Post by petersellers »

arcanemachiner wrote: post #187
petersellers wrote: post #133

Earlier quoted context omitted.

> it’s always been done in that ENVs python shell . What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.

Create a virtual environment: python3 -m venv venv Activate the virtual environment: source venv/bin/activate Deactivate the virtual environment: deactivate

Or: `uvx ruff`

Which one is easier to run, especially for someone who doesn't use python everyday?

Post reply on HN