At present, if a user uses ``networking.stevenBlockHosts.enable = true``
in tandem with ``networking.extraHosts``, the ``extraHosts`` will put be
put after which makes it very difficult to see the custom adds with even
the ``$PAGER`` operating a bit slow due to file size. I would propose
putting this project’s hosts at the end of the hosts file. Meaning:
.. code:: nix
{
networking = {
stevenBlockHosts.enable = true;
extraHosts = ''
127.0.0.1 myproject.localhost
'';
};
}
will now output
.. code::
127.0.0.1 localhost
::1 localhost
127.0.0.1 myproject.localhost
# Title: StevenBlack/hosts with the fakenews extension
#
# …
Format: text/x-rst
Upstream Nixpkgs has been pushing the style of removing ``with lib;``
with the reasoning of clarity around where variables in scope come that
hurt readability & static analysis[*].
While on the topic of ``lib``, introduce ``lib.optional`` &
``lib.optionalString`` in a few more places to tidy up the code while
using common library patterns.
.. [*] https://nix.dev/guides/best-practices#with-scopes
Format: text/x-rst
Pulling in an entire dependency to call a for-loop is wasteful & largely
useless.
When user adds this module to their config, flake-utils & all of its
subdependencies will be pulled into the user’s flake.lock file. This
for-loop was only being used for the developer shell to which a lot of
folks probably aren’t doing active developments in this project as the
module itself doesn’t require it. Potentially damagingly is that this
project lacks its own flake.lock so the latest flake-utils will always
be downloaded regardless of if it that version is compatible or not.
Additionally, flake-utils’ default system list doesn’t include
i686-linux which upstream Python3 in Nixpkgs does.
The alternative solution to these problems is to remove the dependency
& just write a for-loop in this project. This solution could be more or
less robust, but it is an extensible version of that loop that could
handle overlays or config changes if needed in the future.
