New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Jan 5, 2015

Member

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

Member

tibbe commented Jan 5, 2015

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

@rcallahan

This comment has been minimized.

Show comment
Hide comment
@rcallahan

rcallahan Jan 5, 2015

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.

rcallahan commented Jan 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Jan 5, 2015

Member

@rcallahan can you please give steps to reproduce?

Member

tibbe commented Jan 5, 2015

@rcallahan can you please give steps to reproduce?

@rcallahan

This comment has been minimized.

Show comment
Hide comment
@rcallahan

rcallahan Jan 5, 2015

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.

rcallahan commented Jan 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ddssff

ddssff Jan 5, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 5, 2015

Contributor

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

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

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 5, 2015

Contributor

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

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 closed this in 3948f26 Jan 5, 2015

@CRogers

This comment has been minimized.

Show comment
Hide comment
@CRogers

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

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

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Jan 12, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@CRogers

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

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

This comment has been minimized.

Show comment
Hide comment
@victoredwardocallaghan

victoredwardocallaghan Jan 21, 2015

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?

victoredwardocallaghan commented Jan 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hesselink

hesselink Jan 22, 2015

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.

Contributor

hesselink commented Jan 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 22, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@hesselink

hesselink Jan 23, 2015

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.

Contributor

hesselink commented Jan 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 23, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Jan 23, 2015

Member

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

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 added a commit to ezyang/cabal that referenced this issue Jan 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 27, 2015

Contributor

Needs testing.

Contributor

ezyang commented Jan 27, 2015

Needs testing.

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Jan 27, 2015

Contributor

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

Contributor

ezyang commented Jan 27, 2015

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

@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Feb 6, 2015

Member

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

Member

tibbe commented Feb 6, 2015

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

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Feb 6, 2015

Contributor

I think this is good now.

Contributor

ezyang commented Feb 6, 2015

I think this is good now.

@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Feb 6, 2015

Member

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

Member

tibbe commented Feb 6, 2015

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

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Feb 6, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Feb 6, 2015

Contributor

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

Contributor

ezyang commented Feb 6, 2015

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

ezyang added a commit that referenced this issue Feb 6, 2015

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)
@tibbe

This comment has been minimized.

Show comment
Hide comment
@tibbe

tibbe Feb 6, 2015

Member

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

Member

tibbe commented Feb 6, 2015

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

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Feb 14, 2015

Contributor

Halcyon includes a workaround for this issue.

Contributor

mietek commented Feb 14, 2015

Halcyon includes a workaround for this issue.

@mietek mietek referenced this issue Feb 14, 2015

Closed

Improve Cabal version and remote-repo handling #40

4 of 4 tasks complete

cstrahan added a commit to cstrahan/nixpkgs that referenced this issue Mar 13, 2015

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment