Cabal fails to parse build-depends in test-suite block

Question

I am trying to add testing to a package I am working on (I am using stack). Everything worked up until this point. I am running the following versions (as up-to-date as my ubuntu will get):

cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library

Stack: Version 0.1.4.0, Git revision 3a665fe1bc52776041a1c25cc47734e691805b6c (1724 commits) X86_64

This is the offending section:

Test-Suite test-one
  main-is: Test.hs
  type: exitcode-stdio-1.0
  hs-source-dirs: test
  build-depends: base >= 4.7 && < 5
               , scotty >= 0.10.2
               , scotty-login-session
               , text
               , wai
               , wai-extra
               , HUnit
               , HTTP-4000

and this is the error that stack/cabal give when trying to build or test:

Unable to parse cabal file <mypackage>.cabal: NoParse "build-depends" 44

that 44 is the build-depends line above.

What is happening here? I followed the Cabal User Guide, and my google-fu turned up nothing. The rest of the cabal file is linked here for reference.

My system is ubuntu 14.04 LTS if that helps.

Answer 1

The last line should be:

                 , HTTP

and not HTTP-4000. Perhaps you want , HTTP >= 4000.

Here is some more info on the problem...

This is the code in the Cabal library to parse a package name (link)

instance Text PackageName where
  disp (PackageName n) = Disp.text n
  parse = do
    ns <- Parse.sepBy1 component (Parse.char '-')
    return (PackageName (intercalate "-" ns))
    where
      component = do
        cs <- Parse.munch1 Char.isAlphaNum
        if all Char.isDigit cs then Parse.pfail else return cs
        -- each component must contain an alphabetic character, to avoid
        -- ambiguity in identifiers like foo-1 (the 1 is the version number).

Note the comment at the end. Perhaps at one time build-depends: accepted the syntax name-version, e.g. aeson-0.10.0.0, and later this was changed to require use of the relational operators, e.g. aeson == 0.10.0.0.

Now that we always use the relational operators perhaps it might be possible to allow package names with an all numeric component.

In any case, something like foo-123x is a valid package name since the second component isn't all numeric.