Hacker News Reader

Comment by yallpendantools | Hacker News Reader

Can someone please ELI5 what this means for Deno and Python? TFA: "deno is being distributed on pypi for use in python projects" makes it sound like you can now `import deno` and have a JS engine/subsystem in Python, like we finally came full circle from [PyScript](https://pyscript.net/).

However, other comments make it sound like a bunch of other projects have discovered that PyPI is a good distribution channel. Which, to me, sounds like using the Internet Archive as your CDN. Is PyPI the next apt/yum/brew or what?

View on HN

You can, in fact, `import deno` after installing it. But all this gets you is a function that locates the Deno executable, which you can then invoke e.g. with `subprocess.call`.

(I hope this doesn't become a pattern that puts excessive pressure on PyPI. IMO it should only be used for things that are specifically known to be useful in the Python ecosystem, as a last resort when proper Python API bindings would be infeasible or the developer resources aren't there for it. And everyone should keep in mind that PyPI is just one index, operating a standard protocol that others can implement. Large companies should especially be interested in hosting their own Python package index for supply-chain security reasons. Incidentally, there's even an officially blessed mirroring tool, https://pypi.org/project/bandersnatch/ .)

I think it's just so the deno binary is available using pip install. Zig does the same thing.

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?

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)

I'm no expert when it comes to software packaging and distribution issues but this does give off Internet-Archive-as-CDN levels of Hyrum's Law for me. What could possibly go wrong hmmmmmm....

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.

Reply on news.ycombinator.com