Closed SuperCuber closed 3 years ago
Perhaps this can be a stretch goal, not something necessary but nice to have. It's not something a dotfile manager needs to do but it could be convenient.
One extreme case could be on a newly installed system to have pre-deployment hook handle the initial environment setup and software installation then deploy the dotfiles and afterwards post-deployment hook could update all plugins (vim, tmux, ...) and perhaps cleanup some files from the pre-deployment hook installation.
This depends on #37 since the hooks might need elevated privileges.
I thought about it a bit, and this could be good idea:
You can have optional files .dotter/pre_deploy.sh
, .dotter/post_deploy.sh
, .dotter/pre_undeploy.sh
, .dotter/post_undeploy.sh
.
They will be rendered as a template (to allow gathering information from the variables and helpers, for example from the builtin dotter variable), then piped to sh
on linux and cmd
on windows.
This doesn't really depend on #37 because if elevation is needed, the script can just use sudo
on its own.
For pre-hooks, I wonder how it would be possible to have them influence Dotter's environment variables in that case, since the sh
will be a child process of Dotter...
Not sure you're notified so I'll just ping you @RasmusBertell
This sounds very good in my opinion, especially the templating part, it had not occured to me you could do that.
This doesn't really depend on #37 because if elevation is needed, the script can just use sudo on its own.
I remembered reading somewhere that using sudo inside a script was a bad idea, but can't find it anymore and I don't remember the reasoning behind it. I guess that might have been some archaic advise and doesn't hold true anymore, especially since I can't remember the reason behind it, shouldn't blindly follow the conventions just because.
For pre-hooks, I wonder how it would be possible to have them influence Dotter's environment variables in that case, since the sh will be a child process of Dotter...
I didn't know this, learn something everyday. I guess if one needs some environment variables set, then they have to be set manually before running dotter. It's not really a problem, only edge case that I could think of was the new system installation, where you don't have any dotfiles yet.
@RasmusBertell This is implemented as of f031e6b . Please check it out and see if it works like you want.
Right now the implementation is to render it to .dotter/cache/.dotter/pre_deploy.sh
because Windows is stupid and cannot sanely handle commands piped into cmd.exe
, so there it's rendered to .dotter/cache/.dotter/pre_deploy.bat
.
I'm considering whether I should automatically prepend @echo off
on windows deployment...
I'll test this in a few days, tomorrow if I have the time. Thanks for implementing this and for being so active with the project.
Just got around to testing this feature and seems to work fine. Spent about an hour debugging why it didn't run my script only to find out I had named it pre-deploy.sh
instead of pre_deploy.sh
:facepalm: Perhaps there could be some debugging info when no script is found since it always seems to output [DEBUG] [src/deploy.rs:69] Running pre-deploy hook
regardless if it is actually running a script or not.
@RasmusBertell Added in https://github.com/SuperCuber/dotter/commit/33f42b4963d92af24acd9e1ba64d092c5c4abf74
Thanks, that makes it much clearer to see what went wrong. Deployment hooks work well when testing but I haven't tested undeployment hooks, I'd imagine they work just as well.
I couldn't find any mention of this in the wiki. I am willing to write something up for it, but I don't have access to edit said wiki.
@tomodachi94 it's mentioned in https://github.com/SuperCuber/dotter/wiki/FAQ#3-i-want-to-execute-some-commands-before-or-after-a-deploy , and wiki should now be publicly editable. Hopefully the internet doesn't make me regret this :)
Following discussion in #41 and #38 , I think there could be place for being able to execute shell scripts before or after certain operations.
Gotta think how customizable I want it to be - maybe this should involve
local.toml
and be per-machine? For example, It wouldn't make sense to run a plugin update on vim after a deploy if you don't have the vim package selected... Another point is that it could be argued that this is out of scope for a dotfile manager - this kind of behavior can be implemented with a wrapper script.cc @RasmusBertell