Add pre and post build hooks #9899
Conversation
erikd
force-pushed
the
erikd/pre-post-build-hooks
branch
3 times, most recently
from
f40888c
to
56349de
Compare
erikd
force-pushed
the
erikd/pre-post-build-hooks
branch
2 times, most recently
from
c5cd321
to
ed08c4e
Compare
| when (code /= ExitSuccess) $ do | ||
| runBuild |
There was a problem hiding this comment.
This looks like it's not really a hook in the original sense anymore, because it causes an internal cabal phase to be skipped entirely. Why?
The way e.g. git hooks are designed is they just augment existing phases. An error code of e.g. a pre-commit hook, will make the commit as a whole fail.
There was a problem hiding this comment.
We could be more explicit in using the exit code to signal whether or not we want the subsequent action to happen or be skipped. You may want the hook to allow skipping under certain conditions.
| `catchIO` (\_ -> return (ExitFailure 10)) | ||
| when (code /= ExitSuccess) $ do | ||
| runBuild | ||
| -- not sure, if we want to care about a failed postBuildHook? |
There was a problem hiding this comment.
I argue we should. The author of the script can always hide errors of whatever commands they're executing inside the hook.
| code <- | ||
| rawSystemExitCode | ||
| verbosity | ||
| (Just srcdir) | ||
| (hookDir </> "preBuildHook") | ||
| [ (unUnitId $ installedUnitId rpkg) | ||
| , (getSymbolicPath srcdir) | ||
| , (getSymbolicPath builddir) | ||
| ] |
There was a problem hiding this comment.
This needs much more discussion.
- relying on
PATHto find hooks is very improper imo (I see you already changed it)- this should be in something like
~/.cabal/hooksand the user should be able to configure the location via the cabal config
- this should be in something like
- just like git, we should only execute hooks if they're marked as executable (windows is a special case, see how we did it in stack as an example)
- we need a discussion what information we want to expose (e.g. env vars that are available to all hooks, like CABAL_VERSION or GHC_VERSION?)
There was a problem hiding this comment.
The PATH thing has been replaced with looking up ~/.cabal/hooks/.
| , (getSymbolicPath srcdir) | ||
| , (getSymbolicPath builddir) | ||
| ] | ||
| `catchIO` (\_ -> return (ExitFailure 10)) |
There was a problem hiding this comment.
I'm not convinced we should overwrite the exit code of the script?
There was a problem hiding this comment.
there is no exit code. This is file not found mapped to ExitFailure 10. Yes 10 is just a magic constant.
| @@ -678,7 +679,32 @@ buildAndInstallUnpackedPackage | |||
| runConfigure | |||
| PBBuildPhase{runBuild} -> do | |||
| noticeProgress ProgressBuilding | |||
| runBuild | |||
| hookDir <- (</> ".cabal/hooks") <$> getEnv "HOME" | |||
There was a problem hiding this comment.
I think this isn't quite what we want. Cabal has its own logic (e.g. XDG dir, honoring config values, etc.). There must be a set of functions providing those locations.
There was a problem hiding this comment.
Replaced this with:
cabalDir <- dropFileName <$> defaultConfigFile
let hookDir = cabalDir </> "hooks"
There was a problem hiding this comment.
I suggest getDefaultDir XdgConfig "hooks".
erikd
force-pushed
the
erikd/pre-post-build-hooks
branch
4 times, most recently
from
aa2decd
to
5951fc0
Compare
Run a program (named "preBuildHook") before doing a package build and another program (named "postBuildHook") after the package is built. These two programs need to be in ~/.cabal/hooks/ directory. If two or more projects need to use different hooks, dispatch can be done using environment variables. Co-authored: Moritz Angermann <moritz.angermann@gmail.com>
erikd
force-pushed
the
erikd/pre-post-build-hooks
branch
from
5951fc0
to
7f4ea63
Compare
Run a program (named "preBuildHook") before doing a package build and another program (named "postBuildHook") after the package is built.
These two programs simply need to be on the users $PATH variable and are completely generic.
Co-authored: Moritz Angermann moritz.angermann@gmail.com
Related to: #9892
Please read Github PR Conventions and then fill in one of these two templates.
Template Α: This PR modifies
cabalbehaviourInclude the following checklist in your PR:
Template Β: This PR does not modify
cabalbehaviour (documentation, tests, refactoring, etc.)Include the following checklist in your PR: