I created a private repository within `registries/customer-projects`.
This holds flakes.
The folder is registered as registry.
That allows to run the following from within a customer project:
nix run cp\#reuter-phpstan
In order to execute the customer specific application from flake.
The phps used via flake for local development of legacy projects
distributed pre build packages via cachix.
Install cachix and add configuration to allow fetching of pre compiled
packages.
Thanks to https://framapiaf.org/@julm/107764071641134635 for posting the
suggestion.
This should allow me to remove the first entry, as soon as update
migrates from string to list, which I can suggest via PR.
Does not exist yet, add own derivation via overlay.
Exclude tests for documented reasons.
Fix broken indentation in readme.rst
(used as test case for installed rst2pdf);
This scripts is run from shell and created my development environment
(IDE) within a new tmux session.
Don't expect documentation. It was written only for myself.
This is grown and contains fallbacks to old conventions.
Add my very first own derivation (via overlay).
Use existing scripts for dmenu.
"Build" result for nix out of the scripts,
e.g. replace references to nix dependencies.
Create proper output so nix can move it to proper places.
This was previously locally installed from repo and called with system
python3.
Can now be started as "application" which will use the installed
(patched) dmenu.
There is a module for htop, so use that one instead of home.file.
The cool thing is: It has "constants" for some strange integer values.
So nix version is actually readable while the generated config is
strange.
That's a cool pro of nix files.
As we add more and more files, move to set with curly braces.
Maybe home-files is a better approach, but not documented and I don't
understand it to well yet. I guess I've to create a derivation which
"builds" all the files. Maybe to complicated right now.
Might also make sense to build modules for such tools in future where I
can configure within nix, just like git.nix, and it will generate the
config. Might be cool for some things where configs might change, but
the actual things to configure might not. The generation of the file can
change within nix, while configuration within nix stays the same?! ;)
Do not hard code all values, instead configure them within home.nix.
This is more for learning purposes.
But port and allow might also be changed more frequently in general.
home-manager doesn't provide a systemd service itself.
That's why we build one ourself.
That also revealed a change in our directory structure.
The structure is now documented within readme.
Move all packages to home.nix and remove `my-packages` derivate.
Also define dunst service and remove readme entry related to
configuration and services. Those are now maintained via home-manager.
The "update" section in readme got updated to reflect new home-manager.
Daniel Siepmann