Hacker News Reader

> I have a silly theory that I only half joke about that docker/containers wouldn't've ever taken off as fast as it did if it didn't solve the horrible python dependency hell so well.

I don't think this is a silly theory at all. The only possibly silly part is that containers specifically helped solve this problem just for python. Lots of other software systems built with other languages have "dependency hell."

Back in the early days of Redhat, rpm's didn't really have good dependency management. Yes there were rpms, yes you could download them, but getting the full dep tree was a PITA. Most people installed the full Linux distro rather than a lightweight version because of this.

Debian's apt-get was very "apt" at the time when it came out. It solved the entire issue for Debian. There was a point at which there was an apt-rpm for redhat. Yum tried to solve it for redhat, but didn't really work that well -- particularly if you needed to pin packages to certain versions.

I won't touch Python either, but because I've been burned debugging large Python programs. Something that would have taken a minute in a statically typed language took hours of tracing data through the program to understand what was supposed to be in a dict. There are alternative languages that are pithy, statically typed, can write programs quickly, and can grow into large code bases that are maintainable; so there is never a reason to start a new project with Python today.

Most python written at a large scale uses types (TypedDict) and/or Pydantic for safety and never plain dict objects. That's a code smell in any language, we can stuff data into `map[string]interface{}` all day long and cause problems downstream.

There's also dataclass in stdlib

It's fine if the author doesn't choose to do horrendous things. There are types too if you want them, but I don't.

I've seen the same thing in .NET and Java where there's 800 layers of interface and impl and it's an adventure trying to find the actual business logic in all the layers of indirection

>so there is never a reason to start a new project with Python today

Nothing else has an ML/data ecosystem that compares. Perl/Go are maybe a distant 2nd

I deal with that all the time cause an adjacent team uses Java with tons of boilerplate and frameworks. At that point, your static typing isn't so static. Takes them forever to make changes, to the point where I started taking over responsibilities using Python code.

> However, uv has, at least for my beginner and cynical eyes, swept away most of the bullshit for me.

uv is _much_ better than what came before. As someone who has only had only glancing contact with Python throughout my career (terrible experiences at jobs with conda and pip), uv feels like Python trying to actually join the 21st century of package management. It's telling that it's in Rust and clearly takes inspiration from Cargo, which itself took inspiration from Ruby and Bundler.

The funniest thing for me is that you can use uv in mise to install Python cli programs in a surprisingly elegant manner.

Just curious: how?

They may be referring to uvx: https://docs.astral.sh/uv/guides/tools/

Or it could be something else, not sure.

`uv tool install` I believe

In mise.toml I have:

``` [tools] python = "3.12.11" ruff = "latest" ```

I get ruff installed and anything else needed without any fuss.

You can do it with various mise commands, but the simplest way is to use a mise.toml that looks something like this

  [tools]
  python = latest
  uv = latest
  "pipx:yt-dlp" = latest

  [settings]

  [settings.pipx]
  uvx = true

  [settings.python]
  uv_venv_auto = true

These are all features of the [pipx backend] for mise, and the docs discuss what to do in the case of things like python updates, etc. The advantage of doing it this way, particularly for a global mise config, is that you treat these python tools as basically any other mise tool, so their versioning is easy to control.

I know mise isn't really a package manager. But with its support for things like this, be it for python, ruby, npm, or cargo, as well as more universal support from things like Ubi and the upcoming github backends, its rapidly becoming my favorite package manager. I've a number of projects that use particularly useful node based tools, like markdown-lint or prettier, that aren't JS based in any way, shape, or form. Having to carry around a package.json felt weird, and with the way mise handles all of it, now I don't have to

[pipx backend]: https://mise.jdx.dev/dev-tools/backends/pipx.html

> You know something is bad when fancy chrooting is the only ergonomic way of shipping something that works.

Every language seems to have this problem. Or else how can we explain the proliferation of AppImage, Flatpak, Snap, ... ?

Yeah, if you look at a big Python vs Node vs Rust repo side by side, you'll notice Python is often the only one with a Dockerfile.

Basically in the world of C static vs. dynamic linking. A trade-off as old as programming.