Open ii14 opened 2 years ago
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
build
is also what rockspec uses (not that we are tied to it), but I also agree with the naming. Should we specify it by platform? It might get a bit tricky, need to make assumptions if running in powershell, cmd, bash, etc.
We could also call it install_hook
, update_hook
, hook
, etc.
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 git pull/fetch
)?
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.
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
):