Andrew Nesbitt

> Yeah, and ultimately no body cares.

More like hiding their heads in the sand in circumstances that are outside of their ability to fix. None of the tooling or practices out there push you in the direction of not being at risk, or even provide you with easy ways to stay completely safe: no external packages needed to develop software with everything you NEED being provided out of the box, or a flow where pulling in a new package makes you review all of its source code line by line and compile everything instead of any binary tooling blobs, or built in vulnerability and configuration scanning so you don't get pwned by Trivy or don't leave an open S3 bucket somewhere, which also means that obviously you'd need thorough observability and alerting for any of the cloud stuff you do.

And even when they exist, your org projects might be painfully out of date, too much to use those approaches, or the org culture might not be there, or any number of other issues I can't even imagine. On one hand, people are running out of date software and those have CVEs, on the other using dependencies that are too new also puts you at risks of compromised packages - it's like we're being squeezed by rocks on both sides in a landslide or something. Even at the OS level, the fact that everyone is not running something like Qubes OS or regular VMs for development is absolutely insane. The fact that all software isn't sandboxed and that desktop OSes don't prompt for permissions like mobile apps do…

There are two solutions GitHub Actions people will tell you about. Both are fundamentally flawed because GitHub Actions Has a Package Manager, and It Might Be the Worst [1].

One thing people will say is to pin the commit SHA, so don't do "uses: randomAuthor/some-normal-action@v1", instead do "uses: randomAuthor/some-normal-action@e20fd1d81c3f403df57f5f06e2aa9653a6a60763". Alternatively, just fork the action into your own GitHub account and import that instead.

However, neither of these "solutions" work, because they do not pin the transitive dependencies.

Suppose I pin the action at a SHA or fork it, but that action still imports "tj-actions/changed-files". In that case, you would have still been pwned in the "tj-actions/changed-files" incident [2].

The only way to be sure is to manually traverse the dependency hierarchy, forking each action as you go down the "tree" and updating every action to only depend on code you control.

In other package managers, this is solved with a lockfile - go.sum, yarn.lock, ...

[1] https://nesbitt.io/2025/12/06/github-actions-package-manager.html

[2] https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

All of them (well - no HPUX in 15+ years, and I've never used uv in Solaris, or AIX) - but the major two client side environments that I use 'uv' in would be WSL2+Ubuntu/ext4 (work) and macOS/APFS at home.

But - neither the speed nor constant issues with pip/virtualenvwrappers are really a function of the OS/File System.

A frequent theme in this thread (probably most clearly described in https://news.ycombinator.com/item?id=47444936) is that relying on your Python Environment to manager your Python Environment - always ends up in pain. Poetry had this issue as well.

One of the key architectural decisions of Astral was to write the Python Environment Management tooling in rust - so that it could never footgun itself.

It also benefited from very enlightened engineering decisions described here: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

> You’re looking at the number of dependents. The React package has no dependencies.

Indeed.

My apologies for misinterpreting the link that I posted.

Consider "devDependencies" here

https://github.com/facebook/react/blob/main/package.json

As far as I know, these 100+ dev dependencies are installed by default.
Yes, you can probably avoid it, but it will likely break something during the build process, and most people just stick to the default anyway.

> Reproducible builds, or don’t use those packages.

A lot of things are not reproducible/hermetic builds.
Even GitHub Actions is not reproducible https://nesbitt.io/2025/12/06/github-actions-package-manager.html

Most frontend frameworks are not reproducible either.

> don’t use those packages.

And do what?

UV also has the distinct advantage in dependency resolution that it didn't have to implement the backwards compatible stuff Pip does, I think Astral blogged on it. If I can find it, I'll edit the link in.

edit wasn't Astral, but here's the blog post I was thinking of. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s.