Given a freshly scaffolded Yesod application, what is the minimal set of changes necessary to get an executable which acts as a CGI program? A wrapper program is acceptable. If the default executable built by 'cabal build' is a CGI program, what environment variables must be set for it to act as a CGI (as by default it will bind to a port and attempt to serve requests there.)
A similar answer for FastCGI would also be appreciated.
Update your app/main.hs with the following:
import Prelude (IO, (>>=))
import Yesod.Default.Config (fromArgs)
import Yesod.Default.Main (defaultMain)
import Settings (parseExtra)
import Application (makeApplication)
import Network.Wai.Handler.CGI (run)
main :: IO ()
main = fromArgs parseExtra >>= makeApplication >>= run
You'll need to add wai-extra to the dependencies in your cabal file. To use FastCGI instead, replace Network.Wai.Handler.CGI with Network.Wai.Handler.FastCGI and add wai-handler-fastcgi to the dependency list instead.
Related
I have installed tagsoup with
cabal v1-install tagsoup
and verified the install with ghc-pkg list | grep tagsoup
However, in my very simple Haskell 8.6.5 program the statement
import Text.HTML.TagSoup
fails with cannot find module 'Text.HTML.TagSoup'
ghc -v is not useful
cabal new-install tagsoup fails with a ton of errors
import Network.HTTP.Conduit
import Text.HTML.TagSoup
import qualified Data.ByteString.Lazy as BL
import qualified Data.ByteString.Lazy.Char8 as CL
main :: IO ()
main = do
lbs <- simpleHttp "https://wiki.haskell.org"
print $ show lbs
-- tagsoup code removed
For this kind of a single file use case, I'd recommend using a Stack script. If you add the following two lines to the top of your file:
#!/usr/bin/env stack
-- stack --resolver lts-13.27 script
You can then run stack filename.hs, which will:
Download GHC if necessary
Download and build all dependencies, based on your import list
Use runghc to run your program
More information:
How to Script
Get Started with Haskell
I think the only interesting bits are my imports and my cabal file. Here are the imports and the demonstration of how I would use the problematic import (Database.CQL.IO.Log).
module FDS.Database.Cassandra where
import Prelude hiding(init)
import Database.CQL.IO as Client hiding(Logger)
import Database.CQL.IO.Log as CQLLog
import qualified Database.CQL.Protocol as CQL
import Numeric.Natural
import System.Logger (Logger)
cqlLogger :: Logger -> CQLLog.Logger
cqlLogger logger = undefined
However, I get the error:
src/FDS/Database/Cassandra.hs:7:1: error:
Could not load module `Database.CQL.IO.Log'
It is a member of the hidden package `cql-io-1.1.0'.
Perhaps you need to add `cql-io' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
|
7 | import Database.CQL.IO.Log as CQLLog
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But as we can see from the cabal file, it is there:
library
ghc-options: -Wall -Wtabs -Wincomplete-record-updates
default-extensions:
OverloadedStrings
exposed-modules:
FDS
, FDS.Config.Core
, FDS.Config.Dhall
, FDS.Data.Util
, FDS.Database.Cassandra
other-modules:
FDS.Data.Hobo.Defs
build-depends:
prelude
, base-noprelude ^>=4.12
, bytestring ^>=0.10.8.2
, conduit ^>=1.3.1
, containers ^>=0.6
, cql ^>=4.0.1
, cql-io ^>=1.1.0
One thing to note, I do have cql-io in my extra-deps in stack.yaml, as the latest version wasn't yet in LTS.
Q&A from Comments
Q Are there other components in your cabal file (e.g. executables, benchmarks, test suites)?
A Yes
Q Do they also use FDS.Database.Cassandra (but perhaps without depending on cql-io)?
A Not yet, but plan to later. So I haven't touched the other components yet.
Q Does the version of cql-io chosen by your build tool still export Database.CQL.IO.Log?
A It seems to do so.
Q What is the exact command you are running when you see that error?
A stack --nix build The only interesting bit that --nix is doing (AFAIK) is pulling in required system packages, e.g., OpenSSL.
The comments above were very insightful for the general case of the question (as posed); the answer being, sub-libraries that are recently supported by cabal may not have visibility: true declared.
But in my specific case, the answer is to look at the problematic library's re-exports. I could get around this issue because the cql-io authors re-exported Logger (..) and LogLevel(..) from the main library.
So that would allow me to write my code.
An even better answer that is very specific to my situation, as I was trying to use TinyLog, is that there is a library for that already ... here is the code from that library that demonstrates how to get around the issue (and solves the problem for me completely, as I now shouldn't have to write any code).
Here is the relevant excerpt:
module Database.CQL.IO.Tinylog (mkLogger) where
import Data.ByteString.Builder
import Data.ByteString.Lazy (ByteString)
import Database.CQL.IO (Logger (..), LogLevel (..))
import Database.CQL.IO.Hexdump
import qualified Data.ByteString.Lazy as L
import qualified System.Logger as Tiny
-- | Create a cql-io 'Logger' that delegates log messages to
-- the given tinylog 'Tiny.Logger'. Requests and responses are
-- logged on 'Tiny.Trace' level.
mkLogger :: Tiny.Logger -> Logger
mkLogger l = Logger
{ logMessage = tinylogMessage l
, logRequest = tinylogRequest l
, logResponse = tinylogResponse l
}
And here is how I adjusted my imports in the example above to confirm and get GHC happy (though I will scrap this now in favor of using cql-io-tinylog):
import Prelude hiding(init, log)
import Database.CQL.IO hiding(Logger)
import qualified Database.CQL.IO as CQLIO
import qualified Database.CQL.Protocol as CQL
import Numeric.Natural
import System.Logger hiding(defSettings)
I have a directory structure which goes something like this
a
- a.hs
- b
-- b.hs
- c
-- c.hs
I want to import c.hs in to b.hs but I can't work out how to go up a directory and in to b. Typically this would be something like ../c/c.hs.
What is the Haskell way to do this?
Typically you don't save "just code" but modules module ModuleName where. Modules are saved under a file name and path that reflects the module name so you'd have file ADirectory/A.hs (note the capital letter at the start) which starts with module ADirectory.A where and same with the others.
After writing your code people collect the modules into the package.
Sometimes off-handedly called "cabalization" due to using the cabal-install tool (or the alternative, stack), this can be done with cabal init and making sure your cabal file lists each module.
Inside modules such as the file ADirectory/A.hs, you can import the other modules. For example A can import B via import BDirectory.B.
Finally, if it isn't already obvious, the import statements refer to modules which the compiler must already have installed. It isn't possible to import something based on a file system path.
I have a haskell package called prime-tools. When I use stack ghci inside the package directory, I expect it to open up an interactive ghci and automatically import prime-tools. Instead, I find that it loads all of the modules declared in the .cabal file.
For example, here is the extract from my .cabal file showing which modules are declared:
library
-- Modules exported by the library.
exposed-modules: PrimeTools.MathStuff, PrimeTools.Factors, PrimeTools.PQTrials, PrimeTools.Main, PrimeTools.Base, PrimeTools.Lucas
-- Modules included in this library but not exported.
other-modules: PrimeTools.Extras
And this is what happens as I receive the ghci> prompt after running stack ghci in the project folder:
Ok, modules loaded: PrimeTools.MathStuff, PrimeTools.Factors, PrimeTools.PQTrials, PrimeTools.Main, PrimeTools.Base, PrimeTools.Lucas, PrimeTools.Extras.
ghci>
The problem with loading the modules instead of import prime-tools is that I can now use all functions defined in all modules whether or not they are exported.
An example of the issues arising from this distinction: there are two modules in package prime-tools which have implementations of a function called pfactor. One of them is exported, and intended to be used by the end user of the package, while the other is for internal use only and not exported.
Before someone comments, there is good reason to have two implementations of pfactor, but it's not relevant to my question.
My question: how can I use stack to automatically start up a ghci environment with the local version of ghc and import the package whose folder I run the command in?
My desired behaviour would be equivalent to running the following sequence of commands:
stack ghci
ghci> :module -PrimeTools.MathStuff
ghci> :module -PrimeTools.Factors
ghci> :module -PrimeTools.PQTrials
ghci> :module -PrimeTools.Main
ghci> :module -PrimeTools.Base
ghci> :module -PrimeTools.Lucas
ghci> :module -PrimeTools.Extras
ghci> import PrimeTools.MathStuff
ghci> import PrimeTools.Factors
ghci> import PrimeTools.PQTrials
ghci> import PrimeTools.Main
ghci> import PrimeTools.Base
ghci> import PrimeTools.Lucas
The key here is that I want to import the exposed-modules declared in the .cabal file and not to load any modules. I don't mind if the other-modules are also imported, though. Is there a way I can do this using stack without having to run this long sequence of commands every time?
A reasonable workaround is defining a custom GHCi macro for importing your modules the way you want it. Create a .ghci file in your project root along these lines:
:{
:def deload (\_ -> return
":module -PrimeTools.MathStuff\n\
\import PrimeTools.MathStuff"
)
:}
With this, the :deload command in GHCi will remove from scope and then re-import PrimeTools.MathStuff -- you can add as many modules as you want to the list. Though I have written this using multiline string syntax, you can have any String -> IO String expression within the parentheses, so feel free to spell or extend it however you see fit.
I would like to Cabalize a Haskell project in order to upload it to Hackage. It consists of one standard .hs file which builds a bootstrap executable, and eight nonstandard .lhs files which are processed by the bootstrap executable to yield the .hs files which build the production executable.
In other words, my project is a custom literate preprocessor (with HTML markup, code grooming, here documents) which is written in itself. It depends on a bootstrap version which can translate the literate code for the production version, but which is not suitable for general use. So I do not want the bootstrap version to be a separate package; it is meant to be used only once, here.
I have been using a Makefile, which is possible in Cabal but not in the spirit of Cabal. What is a clean way to do this, that takes maximal advantage of the generality of Cabal? I have not seen any suggestions for this in the online documentation, short of either rewriting Distribution.Simple or using a Makefile.
I think that releasing your bootstrap executable as a separate package is the easiest solution, and there are instructions available on how to integrate your custom preprocessor with Cabal.
If you don't want to do that, try making your preprocessor part of Setup.hs (don't forget to set the build type to Custom!). You can run your preprocessor during the configure step. Look at how wxcore does this.
Here's a working example (patterned after wxcore):
Setup.hs:
import Distribution.Simple
import Distribution.Simple.LocalBuildInfo
import Distribution.Simple.Setup
import Distribution.PackageDescription
import Control.Monad (forM_)
import System.Directory (copyFile)
import System.FilePath (replaceExtension)
main :: IO ()
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook }
-- Replace 'copyFile' with more complicated logic.
runMyPreprocessor :: FilePath -> IO ()
runMyPreprocessor abcFile = copyFile abcFile (replaceExtension abcFile ".hs")
myConfHook :: (GenericPackageDescription, HookedBuildInfo) -> ConfigFlags
-> IO LocalBuildInfo
myConfHook (pkgDesc, hbi) flags = do
let extraSrc = extraSrcFiles . packageDescription $ pkgDesc
forM_ extraSrc runMyPreprocessor
confHook simpleUserHooks (pkgDesc, hbi) flags
my-preprocessor.cabal:
name: my-preprocessor
version: 0.1.0.0
build-type: Custom
cabal-version: >=1.8
extra-source-files: Main.abc
executable my-preprocessor
main-is: Main.hs
build-depends: base < 5
Main.abc:
module Main
where
main :: IO ()
main = putStrLn "Hello"