dvershinin

Hey HN, I built pkgdex.org as an alternative to pkgs.org for searching Linux and Unix packages.

What it does: Search packages by name, description, files, provides, or requires across 67 distributions (Fedora, Debian, Ubuntu, Alpine, Arch, FreeBSD, Homebrew, and many more). You can also compare the same package across distros at `/compare/{name}`.

Tech stack: Go templates (SSR, no React/SPA), SQLite (51GB WAL-mode database), Varnish cache, all running on a single 1GB RAM Linode with 4GB swap. Zero-downtime deploys via systemd socket activation.

Why I built it: I work with Linux packaging daily and needed a faster, more comprehensive package search. pkgs.org has been the go-to for years, but I wanted file search (which package provides `/usr/lib/libfoo.so`?), cross-distro comparison, and better coverage of third-party repos.

If you package software or maintain automated builds, you know the drill. You need the latest stable version of some upstream project, and you'd think it's a simple API call. It isn't.

Release tags are wildly inconsistent. Some projects tag `v1.2.3`, others do `release-1.2.3-final`. Quite a few forget to mark their release candidates as pre-releases on GitHub, so the API happily returns a beta as "the latest release". And then there are projects that switch versioning schemes entirely mid-history, going from `v20150121` to `v2.0.1`.

I deal with RPM packaging, so I hit this constantly. Every upstream project required its own script. So I wrote `lastversion` to handle the mess, and it's been in production use for about 7 years now.

  $ lastversion nginx/nginx
  1.26.3

  $ lastversion php/php-src --major 8.2
  8.2.27

  $ lastversion format "mysqld  Ver 5.6.51-91.0 for Linux"
  5.6.51

  $ lastversion rocky
  9.5

That last one pulls Rocky Linux's version from Wikipedia — not everything has a GitHub repo. `lastversion` works with GitHub, GitLab, BitBucket, PyPI, Mercurial, SourceForge, WordPress plugin directory, RSS feeds, Helm charts, and a few others.

The version parsing was the tricky part. Standard PEP 440 doesn't handle real-world formats like Java's `8u462-b08` or OpenSSL's `1.1.1b`, so I extended it. There's also heuristic detection for misfiled betas — when the micro version is suspiciously high (≥90) and it's not a date-based scheme, it's likely a pre-release.

You can also `lastversion download`, `extract`, or `install` releases directly. For CI scripts, the `-gt` flag gives you a non-zero exit code if no newer version exists. And if you maintain RPM specs, `lastversion update-spec nginx.spec` will update the version for you.

`pip install lastversion`. BSD licensed, ~400 GitHub stars.

The no-stdlib limitation is the elephant in the room. Most useful Python isn't pure computation — it's reading files, making HTTP requests, parsing JSON. Without that, you've basically built a safe eval() for math and string manipulation.

The security argument makes sense in theory, but in practice the moment your agent needs to do anything interesting you're back to running real Python with real syscalls. seccomp + namespaces already solve this on Linux without rewriting the interpreter.

I do something similar but with a project prefix. I maintain a lot of packaging scripts and settled on prefixing them by project - gps-build, gps-deploy, gps-sync etc. Tab completion does the rest.

The real issue isn't collisions though, it's discoverability. Six months later you forget half of what you wrote. The prefix at least lets you type gps-<tab> and see everything at a glance.