-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Post-install hook #23
Comments
Nitpick: I'd suggest "build" or "run" over "make", to reflect the more general possibilities for "things I want to do after an install or update". We might also want to be able to say if a hook should run only after install, after install and update, etc |
|
We could also call it |
Some sort of cleanup hook could be useful (to uninstall previous version for example), but is there actually any use case for having the update hook (I assume it's after |
hooks = {
["linux,mac"] = {
build = [[...]],
clean = [[...]],
},
["win"] = {
build = [[...]],
clean = [[...]],
},
}
hooks = {
build = {
["linux,mac"] = [[...]],
["win"] = [[...]],
},
clean = {
["linux,mac"] = [[...]],
["win"] = [[...]],
},
} |
Just a random thought. We could encourage people to use lua/neovim as the environment via which to run these commands: build = {
install = "require('lspconfig').install()",
update = "require('lspconfig').update()"
} And instead ask users to call the build scripts via lua? Otherwise I'm a bit worried about the complexity of having to deal with powershell vs cmd on windows, fish vs. sh vs. zsh vs bash on unix, etc. Otherwise we are going to have to pick a blessed shell per platform and document how the package manager should deal with this (maybe not a big deal). |
One thing to think about is whether this would be opt-in or opt-out. I think with the current set of package managers, they are all opt-in (do to the nature of things currently) and I think some security focused people might want it to stay opt-in, even at a potential lost in ergonomics. |
@mhanberg I think how is it handled should just be implementation defined, and a package manager could let you audit what it is that it's about to run. And plugins can already screw you up if they wanted to, I don't see any particular reason why some malicious actor would prefer doing something nasty here instead of directly inside the plugin. |
vim-addon-manager also uses json to manage dependencies, its "packspec" addon-info.json also specifies hooks |
A somewhat common thing to do is having post-install hooks. Maybe it could be included in the spec?
A couple of ideas for the syntax (not 100% sure about the name
make
):The text was updated successfully, but these errors were encountered: