Detecting and using GHC_PACKAGE_PATH would allow "stack exec" support. This way propellor would be able to be built with
stack build
and run with
stack exec -- propellor ...
see https://github.com/yesodweb/yesod/issues/1018 and https://github.com/yesodweb/yesod/commit/a7cccf2a7c5df8b26da9ea4fdcb6bac5ab3a3b75
I don't think
stack exec propellormakes sense to use. Instead,stack install propellorand then put that in PATH. I've now madepropellor --initknow when it was built using stack, and it will set up propellor to continue to build itself using stack. done --Joey
I don't entirely understand this, though https://github.com/haskell/cabal/pull/2270 seems to give some background. Patches welcome I suppose, although would't it be better to fix the tooling and not things like propellor that just use the tools?
I got Propellor to work with stack by applying this patch (to disable the auto-building):
diff --git a/src/Propellor/CmdLine.hs b/src/Propellor/CmdLine.hs index 5dbc583..b83bb91 100644 --- a/src/Propellor/CmdLine.hs +++ b/src/Propellor/CmdLine.hs @@ -119,7 +119,7 @@ defaultMain hostlist = withConcurrentOutput $ do fetchFirst (onlyprocess (update Nothing)) go _ (Update (Just h)) = update (Just h) go _ Merge = mergeSpin - go cr cmdline@(Spin hs mrelay) = buildFirst cr cmdline $ do + go _ cmdline@(Spin hs mrelay) = buildFirst NoRebuild cmdline $ do unless (isJust mrelay) commitSpin forM_ hs $ \hn -> withhost hn $ spin mrelay hn go cr (Run hn) = fetchFirst $I then replaced the "propellor" binary/symlink with this little wrapper:
```
!/bin/sh
stack build && exec stack exec -- propellor-config "$@" ```
Well, that's simple enough. Although there are a few other places that buildFirst and updateFirst are used, so the patch is not quite complete.
I do want propellor to be able to be used with just cabal. For one thing, Debian stable doesn't even include stack yet! For another, all propellor's haskell dependencies are available in debian so it's overhead for stack to build them all.
But, it'd be nice to support using stack too. If this were configurable in some way that propellor could see, then Propellor.Bootstrap.build could build with stack and update the symlink, and everything else would work as-is.
So, what would be a good way to configure use of stack? It probably would make sense to have it be a property of the Host, which also allows the other bootstrap code to use stack to install dependencies.
And then too, it could look at
GHC_PACKAGE_PATH, so if your ~/.propellor is built using stack once, it will keep on building itself using stack.How about this simple approch: If stack.yaml exists, have propellor use stack for rebuilding itself.
This assimes propellor doesn't ship a stack.yaml, which I think is ok. The user can
stack initto create one.When stack.yaml exists, using --spin would need to get stack installed on the remote host, and use it to build propellor. Much as --spin currently gets cabal and ghc installed and uses them to build.
sm noticed that running the propellor wrapper after stack install propellor sets up ~/.propellor/ but fails to build in there, because it uses cabal.
So, it appeared to him as if the propellor command didn't accept switches, since it never got to the point of running propellor-config. Which is pretty confusing behavior.
To fully support stack, the wrapper or build process would need to notice that it was installed using stack, and build using stack. This conflicts somewhat with my idea about noticing if stack.yaml exists as the flag.