title: Is there any Haskell-land equivalent to the Ruby-land's Bundler et. al and, if not, how would a project so structured be contrived?
body: <p><em>Note to readers</em>: Bear with me. I promise there's a question.</p>
  
  <hr>
  
  <p>I have a problem to solve and think to myself "Oh, I'll do it in Ruby." </p>
  
  <pre><code>$ bundle gem problemsolver
        create  problemsolver/Gemfile
        create  problemsolver/Rakefile
        create  problemsolver/.gitignore
        create  problemsolver/problemsolver.gemspec
        create  problemsolver/lib/problemsolver.rb
        create  problemsolver/lib/problemsolver/version.rb
  Initializating git repo in /tmp/harang/problemsolver
  </code></pre>
  
  <p>Remove the comment on <code>s.add_development_dependency "rspec"</code> in <code>problemsolver/problemsolver.gemspec</code> and then</p>
  
  <pre><code>$ bundle exec rspec --init
  The --configure option no longer needs any arguments, so true was ignored.
    create   spec/spec_helper.rb
    create   .rspec
  </code></pre>
  
  <p>New tests go into <code>spec/</code> and must be in files that end in <code>_spec.rb</code>. For instance, <code>spec/version_spec.rb</code></p>
  
  <pre><code>describe 'Problemsolver' do
    it 'should be at version 0.0.1' do
      Problemsolver::VERSION.should == '0.0.1'
    end
  end
  </code></pre>
  
  <p>To run specs--ignorning code-change runners like <a href="https://github.com/guard/guard" rel="nofollow noreferrer">guard</a>--is trivial:</p>
  
  <pre><code>$ bundle exec rspec
  .
  
  Finished in 0.00021 seconds
  1 example, 0 failures
  </code></pre>
  
  <p>You can't see it, but the message is nicely color coded for quick "Did I screw up?" scanning? The things that are very good about this:</p>
  
  <ul>
  <li>Setup was rapid, almost brainless (though figuring out which commands to invoke is not trivial).</li>
  <li>Standardized layout of the source tree reduces the familiarization period with a new code-base, making collaboration more simple and reducing the lull time when picking up a project you've left for a bit.</li>
  <li>A heavy reliance on tooling distributes best-practices through the community, roughly at the speed of new project creation. </li>
  </ul>
  
  <p>Adding coverage tools, code watchers, linters, <a href="http://cukes.info/" rel="nofollow noreferrer">behavior test tools</a> and others is no more difficult. </p>
  
  <hr>
  
  <p>This stands unfavorably in contrast to the situation if one thinks, "Oh, I'll do it in Haskell." </p>
  
  <pre><code>$ mkdir problemsolver
  
  $ cd problemsolver/
  
  $ cabal init
  Package name [default "problemsolver"]? 
  Package version [default "0.1"]? 0.0.1
  Please choose a license:
     1) GPL
     2) GPL-2
     3) GPL-3
     4) LGPL
     5) LGPL-2.1
     6) LGPL-3
   * 7) BSD3
     8) MIT
     9) PublicDomain
    10) AllRightsReserved
    11) OtherLicense
    12) Other (specify)
  Your choice [default "BSD3"]? 
  Author name? Brian L. Troutwine
  Maintainer email [default "brian@troutwine.us"]? 
  Project homepage/repo URL? 
  Project synopsis? Solves a problem.
  Project category:
     1) Codec
     2) Concurrency
     3) Control
     4) Data
     5) Database
     6) Development
     7) Distribution
     8) Game
     9) Graphics
    10) Language
    11) Math
    12) Network
    13) Sound
    14) System
    15) Testing
    16) Text
    17) Web
    18) Other (specify)
  Your choice? ProblemSolver
  ProblemSolver is not a valid choice.
  Your choice? 18
  Please specify? ProblemSolver
  What does the package build:
     1) Library
     2) Executable
  Your choice? 2
  Generating LICENSE...
  Generating Setup.hs...
  Generating y.cabal...
  
  You may want to edit the .cabal file and add a Description field.
  </code></pre>
  
  <p>"Great," you think, "I was so pestered I bet all the latest Haskell best-practices in software development are just waiting on my disk."</p>
  
  <pre><code>$ ls
  LICENSE  problemsolver.cabal  Setup.hs
  </code></pre>
  
  <p>Allow me to summarize my feelings: <code>:(</code> </p>
  
  <p>The generated cabal file doesn't even have a <code>Main</code> specified, much less <em>instructions</em> for setting up a rudimentary project. Still, okay. If you fart around for a bit trying to find the right search keywords you'll land on <a href="http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program" rel="nofollow noreferrer">How to write a Haskell program</a> which is okay except:</p>
  
  <ul>
  <li>All of Haq source code gets thrown into the root directory.</li>
  <li>The test code for Haq is only in <code>Test.hs</code>, is only QuickCheck and has no facility for continuing the project with split-file tests.</li>
  <li>All of this has to be manually written or copied for each new project.</li>
  </ul>
  
  <p>Checking Real World Haskell's <a href="http://book.realworldhaskell.org/read/testing-and-quality-assurance.html" rel="nofollow noreferrer">Chapter 11</a> you'll find it doesn't even <em>mention</em> cabal and skirts the issue of project layout entirely. None of the resources that Don Stewart kindly answers with <a href="https://stackoverflow.com/a/3120826/314318">here</a> are addressed in either of the aforementioned and, I'll note, Mr. Stewart doesn't explain <em>how</em> to use any of the tools referenced.</p>
  
  <p>Note that the accepted answer in <a href="https://stackoverflow.com/q/3120796/314318">Haskell testing workflow</a> references a project that's since moved on sufficiently so as not be a good answer but <em>does</em> say</p>
  
  <blockquote>
    <p>As cabal test doesn't yet exist -- we have a student working on it for this year's summer of code! -- the best mechanism we have is to use cabal's user hook mechanism.</p>
  </blockquote>
  
  <p>Hey, okay, the cabal documentation! The <a href="http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/#test-suites" rel="nofollow noreferrer">appropriate section</a> does have examples, but they're awfully contrived but don't fail to give the impression that everyone is on their own and good luck to you.</p>
  
  <p>Of course, there's always <a href="https://github.com/batterseapower/test-framework/wiki/Readme" rel="nofollow noreferrer">test-framework</a> that seems to be nice but it example code doesn't offer anything beyond what's seen in the wiki and is non-scalable in the sense that as soon as my program grows in complexity I'm on the hook to develop ways of dividing up tests into manageable modules. I'm not even sure what's going on with <a href="http://hackage.haskell.org/packages/archive/HTF/latest/doc/html/Test-Framework-Tutorial.html" rel="nofollow noreferrer">HTF</a> and agree with <a href="https://stackoverflow.com/questions/8919556/testing-with-htf">Mr. Volkov</a>'s assessment. </p>
  
  <p><a href="https://stackoverflow.com/questions/8919556/testing-with-htf#comment11160690_8919556">Mr. Jelvis</a>' comment on the linked HTF question was of particular interest to me: the Haskell tool-chain suffers, very badly, from a tyranny of small decisions. I can't actually get down to the task at hand--solving my problem in Haskell--because I'm on the hook for getting my environment <em>just</em> right. Why this is bad:</p>
  
  <ul>
  <li>It's wasted effort. Unless I'm writing a test tool, I will very, very rarely care about how my tests are slurped up, only from <em>where</em>. </li>
  <li>It's difficult to learn. There seems to be no singular resource for setting up a project with testing baked in, and the various sources that do exist are sufficiently diverse as to be unhelpful.</li>
  <li>It's difficult to reproduce. With so many moving pieces to arrange I'm bound to do it differently each time.</li>
  <li>As a corollary, it's idiosyncratic. That means its difficult to collaborate and to pick up dormant projects. </li>
  </ul>
  
  <p>This just plain stinks.</p>
  
  <p>Maybe I'm wrong, though. Does there exist some poorly advertised tool or closely developed tools to do something similar to Bundler+Rspec in the Haskell space? If not, is there a poorly advertised canonical example of modern Haskell testing with all of Mr. Stewart's referenced goodies baked right in? The project created or demonstrated:</p>
  
  <ul>
  <li>should by convention and tooling keep test code separate from application code in a well-defined manner (in Ruby-land, Rspec tests go in <code>spec/</code>, Cucumber features in <code>features/</code>),</li>
  <li>should not require  end-users to compile and install testing dependencies</li>
  <li>should be easily reproducible, desirably in no more than 10 minutes and</li>
  <li>should be standardized or have the hope of standardization.</li>
  </ul>
  
  <p>Am I wrong in believing that there's nothing at all like this in Haskell-land?</p>
  
  <hr>
  
  <p>Edit0: Please note, the Ruby language's community isn't the only applicable comparison. Paul R. is correct in identifying the strong current of configuration over convention. Other languages solve the problem of getting a scalable project structure off the ground in other ways:</p>
  
  <ul>
  <li>C :: This language is venerable and so well-documented that you'll have trouble figuring out which well-documented approach to take. No tooling as such.</li>
  <li>Java :: Configuration over convention: you're bound into it at the compiler level. Many tools and very well documented.</li>
  <li>Scala :: Strong tool support.</li>
  <li>Erlang :: Venerable and loosely documented if you know what you're looking for. Arguably configuration over convention if you're using <a href="https://github.com/basho/rebar" rel="nofollow noreferrer">rebar</a> or are otherwise targeting the OTP.</li>
  </ul>
  
  <p>Paul R.'s solution of using a custom template works great if, like C, there's sufficient documentation to compile such a thing. This still runs into issues that I attempted to identify explicitly in the post, but it's workable. Haskell's best offering--that I'm aware of--is "How to write a Haskell program" but falls short of being more than the equivalent of dumping a lone Cub Scout off in the woods with a flashlight and a flask of water. </p>
  
  <p>Also, yes, Static Types are great and do solve many problems that would otherwise need explicit testing. If they were an end-all solution, or mostly sufficient, even, the <a href="https://github.com/snapframework/snap-core/tree/49dc85c3679484205b93fa1edea8be533e252ace/test" rel="nofollow noreferrer">snap-framework</a> would not be so thoroughly tested. (Arguably "Copy snap-core." is an answer to my question.)</p>