This was causing a lot of issues unfortunately presumably due to things
not working with the aarch64 PinePhone system. Random errors like
"expected string 'D'" were common and I'd rather use a separate flake to
make things easier to debug and keep evaluation times to a minimum.
Note that using a separate fork is necessary since overlaying flakes
seems to be non-trivial here.
Also note that previously the nixpkgs hyprland was being started from
greetd. This fixes that.
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.
This change makes it possible to use this nix-config in all the
different ways imaginable (containers, bare metal, tests, and as a
separate flake input) *without* running into infinite recursion
issues with self.
It does this by using a trick similar to JavaScript in which
`var self = this;`, thus enabling the usage of "this" (or self, in
Nix's case) where it wouldn't otherwise be possible.
Note that this *only* works if the input for this repository is named
nix-config. This makes it impractical to combine with multiple
configurations that employ the same strategy.
This change makes it possible to import the modules that are required
from the flake inputs in the output modules themselves, thus preventing
users from having to manually import those modules.
This simplifies things overall and was made possible by the specialArgs
option that allowed these flake inputs to be passed into our container.
Long-term this should make it easy to include all the GUI programs with
the desktop module and all the CLI programs with the shell module, as
well as the ability to easily disable sets of unneeded packages.
Now that I've figured out how to dynamically import modules and use
those modules as outputs, the next step is to ensure that these modules
work as intended when being used by end users.
NixOS offers a built-in testing solution that enables us to conveniently
spin up virtual machines with a given configuration, then verify their
correctness through python scripting.
The lib.nix file in particular is based on Jörg Thalheim's very useful
blog post that explains how to use the built-in testing functionality
with Nix flakes, which isn't covered in official documentation.
See: https://blog.thalheim.io/2023/01/08/how-to-use-nixos-testing-framework-with-flakes/
This makes the code base more portable by *only* depending on Nix as a
dependency.
Note that the code base hasn't been migrated to nixfmt-rfc-style yet.
Having a default.nix doesn't *really* make sense now that we're dealing
with multiple nixosConfigurations, some of which might not even be in
the same flake.
Fixes an issue where the base16-schemes overlay wasn't being applied
presumably due to the separate nixosModule usage.
This removes Qt theming support, so it may be better to simply overlay
base16-schemes inside the module instead.
The code for this is extremely messy right now however it works and I'd
rather not accidentally break it while refactoring, so this commit
serves as documenting the working code.
Now that I have more experience with nix, I know how to write an
expression that automatically outputs all the overlays in the
repository, as well as automatically import them inside the nixos
configuration.
This makes it possible to easily use packages from this repository in
your own separate nix-config flake. This also makes it easier to test
packages locally since `nix build .#package` can be used instead of
building the entire system derivation.
cargo-audit has been dropped to fix an issue with libgit2, which should
be fixed in 1-2 weeks or so. Additionally, nvim-base16 has been renamed
to base16-nvim, which is currently only recognized on -small.
Since my changes are now upstreamed, I no longer need to use a personal
nixos-unstable branch. This makes it easier to use the source code of
the repository and simplifies the updating process.
This one is a lot simpler without all the merge commits in the history.
I should be able to eventually upstream the changes I made to
nixos-containers once I understand how to make those changes
configuration options.
Although I originally wanted to make some cool pull requests for stylix,
it turns out that adding such features would be non-trivial due to the
lack of home-manager support. Since I implemented the functionality I
wanted in my own config already, there's no need to maintain a separate
stylix branch.
Although maintaining my own home-manager repository was a nice learning
exercise, I don't contribute to home-manager enough to warrant having a
personal branch.
Since my pqiv pull request was merged upstream, my branch is basically
the same as upstream anyway.
The white flash when starting hyprland is a deal breaker for me
personally and I'd rather not have to deal with it. Should hopefully be
fixed in a later release since it seems to be a wlroots issue.
Although this was cute, there are simply too many bugs and other
inconveniences to be worth it. For example, the bar cannot be focused
when a workspace has a fullscreen application.
This was my test of the hyprbars fork. It turns out that the original
version is more useful, although both versions crash whenever reloading
the plugin after unloading it once.
This was the only way I could get plugins to work reliably. Might look
into this in the future, but v0.27.2 also includes some changes not
present in v0.27.0.
This lets me do things like only update inputs when I want to.
Additionally, it becomes easy for me to add my own functionality to
these projects and contribute to them upstream. Finally, it becomes
easier to verify changes to the system when pulling changes from
upstream.
This configuration is specifically intended for x86_64-linux and likely
wouldn't work on aarch64-linux. Additionally, the configuration name may
be different than the hostname if desired.
Now I don't have to wait for anything to be included in nixos-unstable
and can simply merge whatever I want whenever I want. This also has the
advantage of not having to specify which input is needed to get a
package from.
The current crystal binary in nixpkgs complains about not finding pcre
when you try to compile anything with it, so crystal-flake is necessary
to have a working crystal environment under NixOS.
crystal-flake additionally packages crystalline, which is nice since no
one has been able to successfully create a pull request for nixpkgs yet.
Reference: https://github.com/NixOS/nixpkgs/issues/129002
