[wpm]

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. You know something is bad when fancy chrooting is the only ergonomic way of shipping something that works.

My first taste of Python was as a sysadmin, back in 2012 or so, installing a service written in Python on a server. The dependency hell, the stupid venv commands, all this absolute pain just to get a goddamn webserver running, good lord. It turned me off of Python for over a decade. Almost any time I saw it I just turned and walked away, not interested, no thanks. The times I didn't, I walked right back into that pile of bullshit and remembered why I normally avoided it. The way `brew` handles it on macOS is also immensely frustrating, breaking basic pip install commands, installing libraries as commands but in ways that make them not available to other python scripts, what a goddamn disaster.

And no, I really have no clue what I'm talking about, because as someone starting out this has been so utterly stupid and bewildering that I just move on to more productive, pleasant work with a mental note of "maybe when Python gets their shit together I'll revisit it".

However, uv has, at least for my beginner and cynical eyes, swept away most of the bullshit for me. At least superficially, in the little toy projects I am starting to do in Python (precisely because its such a nicer experience), it sweeps away most of the horrid bullshit. `uv init`, `uv add`, `uv run`. And it just works*.

[stanleydrew]

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

[bb88]

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.

[762236]

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.

[nijave]

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

[frollogaston]

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.

[mrj]

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.

[nijave]

There's also dataclass in stdlib

[frollogaston]

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.

[asa400]

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

[paradox460]

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

[Ringz]

Just curious: how?

[paradox460]

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

[asa400]

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

Or it could be something else, not sure.

[mrj]

In mise.toml I have:

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

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

[blurbleblurble]

`uv tool install` I believe

[zahlman]

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

[frollogaston]

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.

[dapperdrake]

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