ghc-pkg: cannot create: dist/package.conf.inplace already exists

[mietek]

Build directories (dist) created with cabal-install 1.20.0.3 are not usable with cabal-install 1.22.0.0.

While removing the build directory is a viable workaround, the underlying issue may be manifesting itself in other ways. #2301 seems related.

[tibbe]

@ezyang I guess this is due to switching away from single-file package DBs?

[rcallahan]

Trying to install local packages from a specified .cabal file always fails with this error, and there appears to be no directory I can delete to make it work.

[tibbe]

@rcallahan can you please give steps to reproduce?

[rcallahan]

Removing ~/.cabal worked. Before that, I could delete everything in that directory, create a new sandbox, and I would still get the ghc-pkg error. I don't know what might have been cached in ~/.cabal that would interfere in this way, and it's probably not worth trying to reproduce.

[ddssff]

Right now I have a package with a directory named dist/package.conf.inplace dated December 22nd created by Cabal.1.21.1.0. I now have Cabal-1.18.1.3 installed (that is, 1.21.1.0 has been removed) and if I runhaskell Setup build I get the message Setup: dist/package.conf.inplace: inappropriate type. I think just creating that directory and running "runhaskell Setup build" in almost any cabal tree will give you this error.

I think that in general we need code that removes the file if it is a file and recursively removes the directory if it is a directory in Distribution.Simple.Build.createInternalPackageDB.

[ezyang]

Yeah, the fix for inplace should be simple, cooking it up.

The situation if your .cabal database is single-file is more delicate.

[ezyang]

@rcallahan So, are you sure you deleted your ~/.cabal folder, and that solved the problem, as opposed to your ~/.ghc folder? Because package databases are normally stored in ~/.ghc, although we've stored those as directory-style databases for quite some time now.

[CRogers]

This keeps happening to me, seemingly randomly, whenever I cabal configure or cabal repl a new cabal project. I'm also working on a ide plugin that has a integration test suite which makes a whole load of new cabal projects and runs cabal repl - I get seemingly random test failures from the dist/package.conf.inplace already exists error.

~ $ cabal --version
cabal-install version 1.22.0.0
using version 1.22.0.0 of the Cabal library
~ $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3

I upgraded cabal from 1.20.0.3. I tried deleting (well, moving) my ~/.cabal directory but had no idea how to bring back a new version.

[tibbe]

I think we have a fix in the pipeline for Cabal-1.22.0.1, due later this
month. If you're impatient you can check out the github repo and install an
updated version from there.

On Mon, Jan 12, 2015 at 12:19 PM, Callum Rogers notifications@github.com
wrote:

This keeps happening to me, seemingly randomly, whenever I cabal configure
or cabal repl a new cabal project. I'm also working on a ide plugin that
has a integration test suite which makes a whole load of new cabal projects
and runs cabal repl - I get seemingly random test failures from the dist/package.conf.inplace
already exists error.

~ $ cabal --version
cabal-install version 1.22.0.0
using version 1.22.0.0 of the Cabal library
~ $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3

I upgraded cabal from 1.20.0.3. I tried deleting (well, moving) my
~/.cabal directory but had no idea how to bring back a new version.

—
Reply to this email directly or view it on GitHub
#2320 (comment).

[CRogers]

I installed the master version of cabal but still doesn't work for me. Although I'm starting to suspect it's because my IDE starts up two cabal repl instances at the same time, both of which do a cabal configure. It could be that the first makes a package.conf.inplace and then the second comes along and errors that package.conf.inplace has already been made. I don't know if this would be a legitimate cabal bug (perhaps there should be some form of locking) or I just shouldn't do it.

[victoredwardocallaghan]

Instead of cabal build && cabal install where this issue pops up a direct cabal install after a clean and or clean and configure is a quick work around. Hope that makes sense?

[hesselink]

I'm running the latest HEAD of 1.22, but I'm still getting these errors, or something similar. What seems to be happening is:

• I did an install of a package at some point with cabal-install-1.22. This creates a directory dist/package.conf.inplace.
• Then later I reinstall this package with multiple jobs (-jN, N > 1). This seems to pick some executable from ~/.cabal/setup-exe-cache related to the installed version of the Cabal library, e.g. setup-Simple-Cabal-1.20.0.3-x86_64-osx-ghc-7.8.3.
• This then tries to use the dist/package.conf.inplace as a file, resulting in the error:

setup-Simple-Cabal-1.20.0.3-x86_64-osx-ghc-7.8.3: dist/package.conf.inplace:
inappropriate type

Is there any way to fix this? It seems that either old Cabal versions would have to know how to use the directory versions of the package.conf.inplace, or cabal-1.22 shouldn't create them at all.

[ezyang]

Hmm, I don't think there is a way around this. Probably the best thing we can do is release a minor version update for old versions of Cabal that add directory support.

Let me explain why our hands are tied:

1. This situation is caused by the removal the Cabal dependency from GHC. This is generally considered a good thing, so it would be a shame if we had to back out this change.
2. Removing the Cabal dependency from GHC has the knock on effect that GHC can no longer read single file database because those databases are made using Read instances and we no longer have access to the data type which you would read into.
3. This means Cabal must not output single file databases or later versions of GHC can't read it.
4. However, Cabal never supported inplace directory databases so old versions won't work.

Best to clear the setup cache and try again.

[hesselink]

Clearing the setup cache doesn't work, because it will just recreate the files next time. The only thing that matters is the version of the Cabal library that is installed/in scope. Currently that's 1.20 for me, since I'm on GHC 7.8; I installed cabal-install 1.22 via a sandbox.

I thought about having a point release for 1.20 (and older) to add this support, but I'm not sure it would help much. The biggest reason to keep using the old Cabal library is that it's tied to ghc (in 7.8 and older, at least). If you're installing a new version of it anyway, you might as well install 1.22. Only people who use packages incompatible with 1.22 would benefit from point releases. I'll leave it up to the cabal devs if that's worth it.

It would have been nice to have spread this change out over two GHC/cabal releases: one to add support for the inplace directory databases to cabal (but also keep support for the old format), and one to remove support for the old format. That would have made for a much easier upgrade path.

[ezyang]

OK, here's an alternate suggestion: Cabal should version test GHC to determine if it does a single file or multi file database.

[tibbe]

That makes a lot of sense. Who has time to look into it?
On Jan 23, 2015 1:33 PM, "Edward Z. Yang" notifications@github.com wrote:

OK, here's an alternate suggestion: Cabal should version test GHC to
determine if it does a single file or multi file database.

—
Reply to this email directly or view it on GitHub
#2320 (comment).

[ezyang]

Needs testing.

[ezyang]

OK, seems to DTRT. Waiting for Travis to go green.

[tibbe]

@ezyang is this still something that needs to be fixed in 1.22?

[ezyang]

I think this is good now.

[tibbe]

@ezyang Good as in "everything that's needed is already on the 1.22 branch"?

[ezyang]

According to the discussion on the PR, that seems to be the case. I haven't tested 1.22.

[ezyang]

Actually, I don't see the Version test in the commit list you recently sent out.

[tibbe]

@ezyang it's on the 1.22 branch as 3c0e648.

[mietek]

Halcyon includes a workaround for this issue.