SuperCuber / dotter

A dotfile manager and templater written in rust 🦀
The Unlicense
882 stars 46 forks source link

[FEATURE] Hooks #42

Closed SuperCuber closed 3 years ago

SuperCuber commented 3 years ago

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

Rasmus-Bertell commented 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.

SuperCuber commented 3 years ago

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...

SuperCuber commented 3 years ago

Not sure you're notified so I'll just ping you @RasmusBertell

Rasmus-Bertell commented 3 years ago

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.

SuperCuber commented 3 years ago

@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...

Rasmus-Bertell commented 3 years ago

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.

Rasmus-Bertell commented 3 years ago

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.

SuperCuber commented 3 years ago

@RasmusBertell Added in https://github.com/SuperCuber/dotter/commit/33f42b4963d92af24acd9e1ba64d092c5c4abf74

Rasmus-Bertell commented 3 years ago

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.

tomodachi94 commented 1 year ago

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.

SuperCuber commented 1 year ago

@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 :)