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

Closed
mietek opened this Issue Jan 5, 2015 · 25 comments

Projects

None yet

8 participants

@mietek
Contributor
mietek commented Jan 5, 2015

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
Member
tibbe commented Jan 5, 2015

@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
Member
tibbe commented Jan 5, 2015

@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.

@tibbe tibbe added this to the Cabal-1.22.0.1 milestone Jan 5, 2015
@ddssff
Contributor
ddssff commented Jan 5, 2015

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
Contributor
ezyang commented Jan 5, 2015

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

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

@ezyang
Contributor
ezyang commented Jan 5, 2015

@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.

@ezyang ezyang added a commit that closed this issue Jan 5, 2015
@ezyang ezyang Gracefully handle leftover single file inplace databases, fixes #2320
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
3948f26
@ezyang ezyang closed this in 3948f26 Jan 5, 2015
@CRogers
CRogers commented Jan 12, 2015

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
Member
tibbe commented Jan 12, 2015

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
CRogers commented Jan 12, 2015

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
Contributor

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
Contributor
ezyang commented Jan 22, 2015

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
Contributor

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
Contributor
ezyang commented Jan 23, 2015

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

@tibbe
Member
tibbe commented Jan 23, 2015

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 ezyang added a commit to ezyang/cabal that referenced this issue Jan 27, 2015
@ezyang ezyang Version test whether or not to use single-file package database, helps
…#2320 some more.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
61fdb06
@ezyang
Contributor
ezyang commented Jan 27, 2015

Needs testing.

@ezyang
Contributor
ezyang commented Jan 27, 2015

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

@tibbe
Member
tibbe commented Feb 6, 2015

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

@ezyang
Contributor
ezyang commented Feb 6, 2015

I think this is good now.

@tibbe
Member
tibbe commented Feb 6, 2015

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

@ezyang
Contributor
ezyang commented Feb 6, 2015

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

@ezyang
Contributor
ezyang commented Feb 6, 2015

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

@ezyang ezyang added a commit that referenced this issue Feb 6, 2015
@ezyang @tibbe ezyang + tibbe Version test whether or not to use single-file package database, helps
…#2320 some more.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
(cherry picked from commit 61fdb06)
3c0e648
@tibbe
Member
tibbe commented Feb 6, 2015

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

@mietek
Contributor
mietek commented Feb 14, 2015

Halcyon includes a workaround for this issue.

@cstrahan cstrahan added a commit to cstrahan/nixpkgs that referenced this issue Mar 13, 2015
@cstrahan cstrahan ghc-7.10.1: use a more recent version of Cabal
The version of Cabal bundled with ghc-7.10.1 RC2 has a bug that
prevents cabal-install from working properly with GHCJS.

See: haskell/cabal#2320
e24bbf1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment