This allows to set environment for whole session.
Way better than sending explicit export commands in different shells.
This also allows each new pane to inherit the same environment.
Those tools are expected to be globally available.
Defining runtime input will not expose system wide versions but link
specific versions.
Updating the packages will not update within the environment as custom
project starts a tmux session with the inherited runtime inputs.
Respect new folder structure for reuter.
Move variable initialization into section. Do not initialize if we
already can attach to a session.
Remove legacy database handling. Instead fetch customer name from file
path and concatenate project and customer to database name. This also
supports more deeply nested folder structure within customer folder.
Use writeShellApplication and adjust code to pass shellcheck.
Remove unnecessary overhead after migrating to writeShellApplication.
This involves binary paths as they are imported.
Also rename to custom-project to follow my naming scheme for custom
scripts.
I've added the following myself:
* mattermost
* purple-signald (waiting for https://github.com/NixOS/nixpkgs/issues/188384)
* purple-events
* purple-libnotify
and added slack from nixpkgs.
I'm also trying to make signal integration work.
Not sure whether I'll keep pidgin, as I expect video calls from within
slack not to work.
But would be cool to have a single open source messenger instead of x
instances of chromium as wrapper around closed source web applications.
It didn't work.
Instead I migrated to nix + python directly.
I keep the way to use autocommand to set the formatting.
But no expression but an external program.
This program is created via nix as shell application.
This one uses the sqlparse, just like the plugin.
This will use the std input as file for input.
That way I can re use this in other places.
Integration is way easier, no additional overhead to write python
embedded as vimscript.
Also full dependency control via nix.
No need for overlays.
Instead create own packages and call them via callPackage.
That will keep them simpler and allows dependency injection.
I can follow existing patterns from nixpkgs, etc.
Daniel Siepmann