No real reason to use qutebrowser now that I've written new-tab-identity
and have LibreWolf programmed declaratively.
The additional complexity of having another browser installed meant that
I had to deal with a pyqt6 build error for an application I rarely used
for a number of reasons (no https by default etc.)
Note that glib was supposedly added for mounting-related things, but
this should be possible to upstream into the derivation instead if it
hasn't been added already.
I don't use deno enough to justify having separate abbreviations for it,
and I doubt I will anytime soon due to the vastly superior ecosystem of
npm. Just as an example, `deno task` autocomplete support isn't
implemented, whereas `npm run` does have autocomplete.
`deno add` is now preferred over `deno install`. Additionally, `deno
compile` doesn't work on NixOS, and creating a derivation should be
preferred instead.
This is part of migrating scripts from ~/.local/bin to the nix-config.
Note that this also lets us use packages that aren't available in a
user's $PATH.
I originally thought I was going to use bun, but it turns out that there
are simply too many inconveniences compared to using npm itself, which
includes built-in nixpkgs support with buildNpmPackage and vastly
superior shell completions among other things.
Rust programs are easy enough to install The Nix Way so there's no real
reason to put .cargo in $PATH, especially when programs that have
dependencies like openssl won't work this way.
It turns out I don't use deno nearly as much as I thought I would,
especially when the current node ecosystem works so, so well in
comparison.
I also haven't encountered any deno-specific programs that would be
worth installing globally.
Shouldn't be needed since I'm no longer interested in long-term Go
development. For when I *do* need to use Go, those packages can be
built as Nix derivations.
I'll still use pnpm when I *need* to, however the lack of support for
pnpm in nixpkgs is a show-stopper I'd rather not have to deal with when
npm works out of the box.
pnpm was originally used for faster install times and pnpm workspaces,
however npm now has its own workspaces and I'm okay with slower install
times if it means that everything works without fragile workarounds.
Yarn has been outdated for a while now, especially with the failure for
new projects to switch to "berry" among other things. I should never
need to use it again, but if I do, I don't need the abbreviations.
Yarn was originally used for yarn workspaces and faster install times.
Nowadays, however, other package managers are able to do both in more
efficient ways.
