"Couldn't parse package identifier depends" output nothing

[snowmantw]

When I execute the installed hsenv, it will generate nothing in the .hsenv/bin dir and dump errors both in log and stderr :

_( from sterr )_
Creating Virtual Haskell directory structure
Installing GHC
Initializing GHC Package database at /tmp/testenv/.hsenv/ghc_pkg_db
Copying necessary packages from original GHC package database
Couldn't parse package identifier depends:

hsenv.log file contains detailed description of the process.

I've check the hsenv.log file, and it shows the error was caused by Cabal-1.14.0 which had been installed by cabal-install :

Copying package Cabal-1.14.0 to Virtual Haskell Environment
    _(... ignore many ENV outputs)_
    Process error output:
        ghc-pkg: cannot find package Cabal-1.14.0
It's not.
Extracting dependencies of Cabal-1.14.0
    Running system's version of ghc-pkg
      Executing: ghc-pkg field Cabal-1.14.0 depends
        using inherited variable environment
        Process exited successfully
        Process output:
          depends: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46
                   base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702
                   _(... ignore many depends outputs)_
          depends: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46
                   base-4.5.0.0-40b99d05fae6a4eea95ea69e6e0c9702
                   _(... ignore many depends outputs)_
        Process error output:
    Found dependency strings:  _( it's a horrible long string)_

Couldn't parse package identifier depends:

The last line should output something, but it didn't . And the ghc-pkg check command can only find some warnings about haddock . This problem has been reported in the pre-renaming virtualenv repo , and it still open .

My platform :

• Ubuntu 12.04 server
• GHC 7.4.1
• cabal-install_0.10.2-3_amd64.deb

And the hsenv.cabal file had been modified to fit new dependencies . I admit that may cause problems, but my situation is nothing output from a line, which should print what's wrong happened .

[snowmantw]

Ok, after tracing codes and doing some testings, the problem seems caused by Cabal 1.14 ( or something else effecting it ) , which will print the depends twice . And ( maybe ) the parsePkgInfo went wrong because it receive the second 'depends:' string as an package info string. I will do more testing about the Cabal-printing-depends-twice problem to confirm it.

But the "Couldn't parse package identifier depends" error message still append nothing after it. So I can't find any useful info according to the message, unless modifying the codes.

[snowmantw]

After I remove the Cabal package installed by cabal-install , the problem disappeared. So I think the ghc-pkg shows two Cabal 's depends at the same output.

And why my computer has 2 Cabal packages ? The cabal-install has complained that hsenv need Cabal package ( not cabal pkg-management ... ) . so I install it by cabal-install , to let hsenv building works.

[lostbean]

I had the same problem here, for some reason the packages Cabal and directory were installed a second time, one (the original) for global users and the second for the local user. As suggested by snowmantw, the ghc-pkg unregister solved the problem.

[snowmantw]

I think the best solution is to modify related codes in parsePkgInfo, and make it more robust. Maybe adding a filter to get rid of those duplicated info is the cheapest way. But I don't know whether it's a feature or a bug, that cabal-install allow install a same package twice.

[Paczesiowa]

I can confirm, that having Cabal (and probably any other base package) installed globally and in user db will break hsenv.

fixing parsePkgInfo (actually getDeps from PackageManagement) seems easy, but I suspect it will break if the wrong copy of Cabal is chosen. anyway, I won't fix it, because I think the whole process of re-using global ghc db is wrong and I will probably remove it in the future (it will simplify the code base a lot). I think using ghc from tarballs is cleaner and safer. to get rid of re-using global ghc db, first I have to implement caching of ghc installs, to not blow disk space usage and make it faster when creating many environments with the same ghc version.

anyway, you can use hsenv with ghc from tarball (even if it's the same version as your global one), creating environments will be slower, and you will lose more space, but it will work correctly in your situation.