Note that deno was removed since it still fails to handle things like
Next.js with the 2.0 release candidate and I'd rather not have to deal
with all the other issues I faced while trying to use it with React.
- GIT_DISCOVERY_ACROSS_FILESYSTEM shouldn't be needed anymore and was
likely a skill issue in the past.
- NODE_OPTIONS should be set per-project instead of globally.
- GATSBY_TELEMETRY_DISABLED should also be set per-project, although the
framework seems to be in standby mode currently.
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.
The year is 2024 and httpie is no longer in fashion. httpie was broken
on NixOS anyway due to certificate verification errors, and wget is
unnecessary overall since scripts that depend on it have their own $PATH
with it available.
See: https://github.com/NixOS/nixpkgs/issues/94666
rustscan is a nice alternative to nmap that's easier to use and doesn't
require the usage of sudo in certain situations.
nix-update is a nice script that makes updating the versions and hashes
of packages way easier than editing them by hand.
It's better to be pragmatic here and not choose tectonic when texlive
works extremely well and without any of the problems one would encounter
with tectonic.
The future of tectonic is unfortunately a mystery as well, due to the
status of the GitHub repository and its dependence on the unmaintained
XeTeX.
See: https://tex.stackexchange.com/questions/593031/what-are-the-downsides-of-using-xetex/593217#593217
Now that tmux works again, it makes sense to choose it over zellij due
to the vastly superior community support around it. Using tmux-256color
makes colors work properly in programs like htop, and neovim benefits
from squiggly lines and italics from kitty as well.
Dropped some extra cargo dependencies since I'd rather only use what's
available in cargo. Also added statix since it seems to catch some
things not found by nixd.
This was used for "cargo upgrade" however there have been major
improvements to cargo since I added this and dependabot on GitHub
handles this better anyway.
One major downside of cargo-edit was that it would take a very long time
for the initial upgrade to occur, which made me use "cargo update" more
anyway to avoid the long wait times.
Avoids having a separate home module just for packages and makes
essential tooling accessible in all shells.
Note that the legacy `texlive.combined.scheme-full` was replaced with
`texliveFull` in this commit.
Note that we will continue to use nixpkgs-fmt for the time being here
since nixfmt-rfc-style breaks string syntax highlighting and comments
like `/* this */` get turned into `# this`.
The conversion from lisp-like formatting to something else in flake.nix
is a bit unfortunate, but I'd rather have a singular style for the
entire code base to make things easier.
Realistically this might be more related to "system" than shell, however
it may also be advantageous to keep system as minimal as possible since
it could also be argued that interpreted programming languages are a
part of the system.
There is currently a bug where yazi crashes since it tries to create
directories but is unable to due to being managed at the system level.
There is an open PR in nixpkgs, however it's been 3 weeks and it hasn't
been merged yet.
This is a part of making it easier to instantly have access to yazi
without having to worry about using home-manager. Note that this works
for my use case since I don't use Nix on non-NixOS devices and don't
intend to do so anytime soon.
Realistically I want access to htop on any machine running my shell
configuration. Making this NixOS-specific removes some of the dependence
on home-manager as well.
I originally separated these modules to avoid "opinionated" options like
neovim as the default editor. Now I realize however that it's easier to
load all opinionated settings by default since users can change them
either through the original options or with module-specific options.
By making this module more generic, it becomes possible to include CLI
programs and other applications as part of the "shell", then provide
options for users to enable or disable things as needed.
