Comment by Imustaskforhelp | Hacker News Reader

Comment by Imustaskforhelp | Hacker News Reader

Parent Full thread

Imustaskforhelp

> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI).

UV scripts are great for this type of workflow

There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and everything included and would work everywhere

https://paulw.tokyo/standalone-python-script-with-uv/

Personally I end up just downloading uv and so not using the uv download script from this but if I am using something like github action which are more (ephemeral?) I'd just do this.

Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times

That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python)

I am interested in bun-shell as well but that feels way too much bloated and even not used by many so less (AI assistance at times?) and I haven't understood bun shell at the same time too and so bash is superior to it usually

> UV scripts are great for this type of workflow

So previously when I have seen Python used as a task runner I think they used UV to call it. Although I don't think they had as a complete solution as your here auto-installing UV etc.

Although the example you've linked is installing UV if missing, the version is not pinned, I also don't think it is handling missing Python which is not pinned even if installed locally. So you could get different versions on CI vs locally.

While yes you are removing some of the dependencies problems created via using Python over Make/Shell I don't think this completely solves it.

> Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times

I personally haven't witnessed anytime I would consider the scales to have tipped in favour of Python and I would be concerned if they ever do, as really the task runner etc should be plumbing, so it should be simple.

> That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python)

Using Python/UV to do anything more complex than my example PR above?

I think UV scripts can/will actually install python and manage it itself as well and you can actually pin a specific version of python itself via Uv scripts

I copied this from their website (https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...)

uv also respects Python version requirements: example.py

# /// script # requires-python = ">=3.12" # dependencies = [] # ///

# Use some syntax added in Python 3.12 type Point = tuple[float, float] print(Point)

> Using Python/UV to do anything more complex than my example PR above?

I can agree that this might be complex but that complexity has a trade off and of course nothing is shoe fits all but there are times when someone has to manage a complex CI environment and I looked at and there are some CI deterministic options too like invoke etc. and when you combine all of these, I feel like the workflow can definitely be interesting to say the least

Once again, I don't know what really ends up in github actions since I have never really used it properly, I am basing its critiques based on what I've read and what solutions (python came quite frequently) and something recently which I discovered (which was the blog)

This thing does a global uv install when run? That's obnoxious! Never running stuff from whoever wrote this.

Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.

Does it really matter if its a global install of uv or not especially on Github Actions

Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you

> Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.

Regarding author suggest its removes itself its because it does still feel clutterish but there is virtually 0 overhead in using/having it still be if you are already using uv or want to use uv

Oh also, (I am not the Author) but I have played extensively with UV and I feel like the script can definitely be changed to install it locally rather than globally.

They themselves mention it as #overkill on their website but even then it is better than whatever github action is

I'm a huge believer in the rule that everything GH actions does should be a script you can also run locally.

Yes I believe the same too and I think we are on the same goal. I think that I can probably patch this code to install uv, let's say locally instead of globally if that's a major concern. I feel like its not that hard.

It's easy enough to patch. It's the philosophy that bugs me. We already have a huge problem with routine workflows pulling things from the network (often, without even a semblance of hash-locking) and foregoing the traditional separation between environment setup and business logic. There's a lot of value into having discrete steps for downloading/installing stuff and doing development, because then you can pay special attention to the former, look for anything odd, read release notes, and so on. Between explicit, human-solicited upgrades, dev workflows should be using, ideally, vendored dependencies, or, if not that, then at least stuff that's hash-verified end-to-end.

Someday, someone is going to have a really big disaster that comes out of casual getting unauthenticated stuff from somebody else's computer.

I agree with you and you raise some good points

I think your reason of worrying is either that A) packages can update and contain malware or B) Uv's installation itself. might have malware if any of A) or B) get hacked

Regarding A) I feel like uv's dependencies can be pinned to a certain date to make them reproducible and this can come of help (https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...)

Regarding B) I feel like they provide attestations via GitHub Artifact Attestations and the script could once again be modified to actually verify it via github attestations and they also provide ghcr artifacts (as such immutability) atleast of docker images and I looked further into it and it seems that you can use github artifacts to upload normal binary files as well so I will probably take a look into seeing if I can do something like this for uv's ghcr

Effectively after A) and B) the trust just ends up being reliant on Github's Microsoft infrastructure (usually) and perhaps python infrastructure which is on fastly

But I feel like this is for cases of extremely sensitive workflows But I feel like I might still take a look at it because security still feels very interesting to me and just because of this discussion, I can see at some pointers of following up on curiosity lol

Anyways would love to continue our discussion and probably update you on trying to make a script which could actually be completely pinned (atleast uv binary instead of just running a shell script from the astral servers in such case)

Reply on news.ycombinator.com