Feature request: pre-build hooks

[kgadek]

The example use case: Protocol Buffers. The generate *.hs files. The latter shall not be in the repository itself, however they take part in the other-modules section in *.cabal files.

It would be great if there was a way to execute protoc compiler before calling the actual building. Then, no wrappers around both tools (protoc & stack) would be required.

[snoyberg]

I'm +1 on this in principle. One thing to point out is that this will start moving us toward a world where some projects cannot be built with cabal at all, only stack. I'm OK with that, since this is clearly an opt-in case.

Check out #472 as well for some related concepts.

Can you describe in more details exactly what you'd like to see the functionality be here? There are some interesting questions about how the command is specified, when it's run (every time? detect that a file is dirty? etc).

[DanBurton]

Isn't this something that falls into the realm of Setup.hs? I would lean
towards sticking with cabal-the-framework unless there's a compelling
reason to deviate.

On Friday, July 3, 2015, Michael Snoyman notifications@github.com wrote:

I'm +1 on this in principle. One thing to point out is that this will
start moving us toward a world where some projects cannot be built with
cabal at all, only stack. I'm OK with that, since this is clearly an opt-in
case.

Check out #472 #472 as
well for some related concepts.

Can you describe in more details exactly what you'd like to see the
functionality be here? There are some interesting questions about how the
command is specified, when it's run (every time? detect that a file is
dirty? etc).

—
Reply to this email directly or view it on GitHub
#503 (comment)
.

-- Dan Burton

[rvion]

Also, should we think about windows compatibility before it's too late ?

[kgadek]

The reason for this feature request is that Setup.hs is sometimes… too late. So let's see another example and please excuse the rant against Cabal.

< rant >
One of the things that is wildly annoying in cabal – the-file-format – is the inability to express "export everything". Since I believe the computer is a better performer at find <SRCDIR> -type f -iname '*.hs', this is just pure nonsense to require programmer to include all of his files to be in either main-is, other-modules, or exposed-modules section. This is true while refactoring or for util libraries. This export-all would allow to use conventions like "don't touch Internal.*' above the actual restriction.

edit: The funny thing about this is that the problem is in the Haskell report itself, since it doesn't state what filename shall be given for the module. For A.B.C, GHC uses A/B/C.hs though I heard on IRC that at least one compiler uses A.B.C.hs. The funny thing is that anyway this looks like, cabal has already this search-like capability for both conventions; I believe cabal runs this code during cabal init: haskell/cabal:cabal-install/Distribution/Client/Init/Heuristics.hs#L127 . So… yeah, exactly what everyone needs.
< / rant >

What I want to achieve is to have the foo.cabal-template from which the foo.cabal would be generated to bypass this single deficiency in pure Cabal – the-file-format.

[kgadek]

@snoyberg the simplest and most precise solution for my use-case would be to run command passed in (optional, project specific) preprocess key in config file.

However, I believe that stack could use the idea of hooks, like in git. Then, any reasonable action could get scripted in arbitrary way. Compatibility with Windows would not be a problem (responsibility on the hook developer). There could be two ways to do that:

1. the stack/hooks dir that contains appropriately named hooks.
2. there are project-specific, optional params like pre-build, pre-read-cabal, etc.

I like the second more.

On the downside, there are two problems.

1. security. By calling stack build foo, the creator of foo could call arbitrary command on my computer. Git solves this by not propagating hooks to clones (requires manual intervention to use them), stack does not seem to have this level of control over downloaded files.
2. portability. In what language shall be the hooks written in? It could be Haskell. Also I believe it's not a deficiency since – as you've mentioned – this is opt-in. And the responsibility is again on the developer.

As for the security, one solution is to allow running hooks only from .git/stack dir (the good: not automatic hook assignment. The bad: this is intrusion into the git layout. The ugly: would require git). Or ask the user while downloading if the hooks are to be used? Or introduce new command use-hooks?

I have no great idea for this right now.

[snoyberg]

It sounds to be like what you really want is #259. I'd rather not try to push in a halfway solution to the problem. Can you look over that issue and let me know if something like that would address your concerns?

[snoyberg]

Looks like we're going to not be pursuing this right now, and instead using Setup.hs files for now (as bad as they are) and eventually considering a replacement for .cabal files.