For those less in the know: is it for convenience? Because most systems have a package manager that can install Python, correct? But `pip` is more familiar to some?

I think it’s more for Python libraries that depend on JavaScript.

Lots of packages rely on other languages and runtimes. For example, tabula-py[1] depends on Java.

So if my-package requires a JS runtime, it can add this deno package as its own dependency.

The benefit is consumers only need to specify my-package as a dependency, and the deno runtime will be fetched for free as a transient dependency. This avoids every consumer needing to manage their own JavaScript runtime/environment.

https://pypi.org/project/tabula-py/

The zig one allows you to build native modules for your python project from setup.py without having to have a C/C++ toolchain preinstalled. Here's a talk about this:

https://www.youtube.com/watch?v=HPmefnqirHk

It's because when you use the native Python packaging tools, you can install a Python "wheel" into an arbitrary Python environment.

If you get Deno from the system package manager, or from deno.com directly, you're more constrained. Rather, it seems that you can set an environment variable to control where the Deno home page installer will install, but then you still need to make your Python program aware of that path.

Whereas a native Python package can (and does, in this case, and also e.g. in the case of `uv`) provide a shim that can be imported from Python and which tells your program what the path is. So even though the runtime doesn't itself have a Python API, it can be used more readily from a Python program that depends on it.

Pypi is the only OS agnostic package manager already installed on every OS.

Also, it's VERY convenient for companies already using python as the primary language because they can manage the dependency with uv rather than introduce a second package manager for devs. (For example, if you run deno code, but don't maintain any JS yourself)