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.