Good news for future yt-dlp releases (cf. https://news.ycombinator.com/item?id=45898407), which could now mark it as an optional dependency available through Python's native packaging.
Update: I lobbed the idea over on the yt-dlp issue tracker. The initial response has been skeptical, citing some issues (which I agree about) with the current state of the Deno packaging. But I'm optimistic that this can be sorted out eventually.
It would be pretty magical if this simplifies bundling static assets in Python applications, letting us avoid independently installing and running the Node toolchain.
Quite interesting to observe PyPI being used as a distro agnostic binary package manager. Someone is going to create a NixOs competitor that uses PyPI for hosting and uv for installation.
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?
I'm not crazy about the way this installs Deno as `/usr/local/bin/deno` (on Linux systems at least). I was hoping it would leave that executable tucked away in Python site-packages somewhere out of the way.
This shouldn't be possible as long as you get a wheel (try configuring the installer to require wheels). The download script in the source distribution can do what it wants, of course, and I agree that this isn't the greatest behaviour.
My guess is that they do this in order to put the binary in a specific location of a container, as part of their own build process. The ecosystem doesn't distinguish between "source distributions" intended to build on a user's vs. developer's machine.
11 comments
[ 4.0 ms ] story [ 27.1 ms ] threadPyPi: https://pypi.org/project/deno/
GitHub: https://github.com/denoland/deno_pypi
(Note that the GitHub link in the first post of the issue linked by this HN post now redirects to the official location, as of the time I write this.)
Other cool tools you can install from pypi:
1. https://pypi.org/project/cmake/
2. https://pypi.org/project/ninja/
3. an entire c/c++/zig toolchain: https://pypi.org/project/ziglang/
4. the nvcc cuda compiler: https://pypi.org/project/nvidia-cuda-nvcc/
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?
The wheel comes in five flavors: https://pypi.org/project/deno/#files - Windows x86, manylinux x86 and ARM64, macOS x86 and ARM64.
That's a lot of machines that can now get a working Deno directly from PyPI.
I also ran into some weird issues where sometimes the binary isn't executable and you have to chmod +x it - including in GitHub Actions workflows. I had to workaround it like this: https://github.com/simonw/denobox/blob/8076ddfd78ee8faa6f1cd...
My guess is that they do this in order to put the binary in a specific location of a container, as part of their own build process. The ecosystem doesn't distinguish between "source distributions" intended to build on a user's vs. developer's machine.