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

yesod-bin: devel cannot satisfy -package-id main #1284

Closed
spl opened this Issue Oct 5, 2016 · 29 comments

Comments

Projects
None yet
4 participants
@spl

spl commented Oct 5, 2016

I'm upgrading an application from lts-5.16 (GHC 7.10.3) to lts-7.1 (GHC 8.0.1), and I'm seeing the following error when running yesod devel:

<command line>: cannot satisfy -package-id main
    (use -v for more information)

I ran yesod -v devel, and, indeed, I see a -package-idmain tacked on to the runghc command.

I thought it might be due to the upgrade of yesod-bin from 1.4.18.1 to to 1.4.18.3, but I tried 1.4.18.1 with the new application version, and it gave me the same problem.

A diff of the runghc command string of the two versions of my application appears mostly as expected (changes in version numbers) except for one odd difference. In the old version, there is -package-keyworkf_0ceLnjmRnbSBeWHnCnoeyy, but in its place in the new version appears -package-idmain.

There are a number of differences between the two versions of the application; however, nothing in the changes of the .cabal or stack.yaml would appear to cause this. They are all dependency version changes or extra-deps changes.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 5, 2016

I wonder if this could be related to the GHC 8.0 changes: 833e74e. cc @erikd

spl commented Oct 5, 2016

I wonder if this could be related to the GHC 8.0 changes: 833e74e. cc @erikd

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 5, 2016

Also, that difference I mentioned above appears as the last argument to runghc before devel.hs.

spl commented Oct 5, 2016

Also, that difference I mentioned above appears as the last argument to runghc before devel.hs.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 5, 2016

If I'm reading the order of the list items from 833e74e correctly, seems like the reason for the -package-key vs -package-id difference is due to this change:

-#if __GLASGOW_HASKELL__ >= 710
+#if __GLASGOW_HASKELL__ >= 800
+    packageString flags = "-package-id" ++ Module.unitIdString flags
+#elif __GLASGOW_HASKELL__ == 710
     packageString flags = "-package-key" ++ Module.packageKeyString flags
 #else
     packageString flags = "-package-id" ++ Module.packageIdString flags ++ "-inplace"
 #endif

spl commented Oct 5, 2016

If I'm reading the order of the list items from 833e74e correctly, seems like the reason for the -package-key vs -package-id difference is due to this change:

-#if __GLASGOW_HASKELL__ >= 710
+#if __GLASGOW_HASKELL__ >= 800
+    packageString flags = "-package-id" ++ Module.unitIdString flags
+#elif __GLASGOW_HASKELL__ == 710
     packageString flags = "-package-key" ++ Module.packageKeyString flags
 #else
     packageString flags = "-package-id" ++ Module.packageIdString flags ++ "-inplace"
 #endif
@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 5, 2016

So it appears that "main" is the Module.unitIdString, but I have no idea where it's coming from.

Just reading the following from Module.hs:

  1. UnitId: A ComponentId + a mapping from hole names (ModuleName) to Modules.
  2. When Backpack is not being used, UnitId = ComponentId.
  3. ComponentId: An opaque identifier provided by Cabal, which should uniquely identify such things as the package name, the package version, the name of the component, the hash of the source code tarball, the selected Cabal flags, GHC flags, direct dependencies of the component. These are very similar to InstalledPackageId, but an 'InstalledPackageId' implies that it identifies a package, while a package may install multiple components with different 'ComponentId's.
  4. Same as Distribution.Package.ComponentId.

spl commented Oct 5, 2016

So it appears that "main" is the Module.unitIdString, but I have no idea where it's coming from.

Just reading the following from Module.hs:

  1. UnitId: A ComponentId + a mapping from hole names (ModuleName) to Modules.
  2. When Backpack is not being used, UnitId = ComponentId.
  3. ComponentId: An opaque identifier provided by Cabal, which should uniquely identify such things as the package name, the package version, the name of the component, the hash of the source code tarball, the selected Cabal flags, GHC flags, direct dependencies of the component. These are very similar to InstalledPackageId, but an 'InstalledPackageId' implies that it identifies a package, while a package may install multiple components with different 'ComponentId's.
  4. Same as Distribution.Package.ComponentId.
@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

I'm using Cabal and cabal-install versions 1.24, in case that makes a difference.

spl commented Oct 6, 2016

I'm using Cabal and cabal-install versions 1.24, in case that makes a difference.

@erikd

This comment has been minimized.

Show comment
Hide comment
@erikd

erikd Oct 6, 2016

Contributor

I see the error:

<command line>: cannot satisfy -package-id main
    (use -v for more information)

if I'm building in a cabal sandbox and I switch from say ghc-7.10 to ghc-8.0. The solution is usually to do cabal clean.

Contributor

erikd commented Oct 6, 2016

I see the error:

<command line>: cannot satisfy -package-id main
    (use -v for more information)

if I'm building in a cabal sandbox and I switch from say ghc-7.10 to ghc-8.0. The solution is usually to do cabal clean.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

@erikd: Thanks. I'm glad you could reproduce it. Is there something yesod-bin could do to prevent this?

I tried cabal clean, and it didn't work.

I'm working in a stack project. I'm actually doing stack exec -- yesod devel. I already tried stack clean without luck. I'll try rm -rf .stack-work now, make everything rebuild, and try again.

spl commented Oct 6, 2016

@erikd: Thanks. I'm glad you could reproduce it. Is there something yesod-bin could do to prevent this?

I tried cabal clean, and it didn't work.

I'm working in a stack project. I'm actually doing stack exec -- yesod devel. I already tried stack clean without luck. I'll try rm -rf .stack-work now, make everything rebuild, and try again.

@erikd

This comment has been minimized.

Show comment
Hide comment
@erikd

erikd Oct 6, 2016

Contributor

I didn't reproduce, I've just seen it before, and it wasn't anything yesod related, just using cabal sandboxes and switching between compiler versions.

Contributor

erikd commented Oct 6, 2016

I didn't reproduce, I've just seen it before, and it wasn't anything yesod related, just using cabal sandboxes and switching between compiler versions.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

@erikd: Ah, okay. Thanks.

spl commented Oct 6, 2016

@erikd: Ah, okay. Thanks.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

Due to https://ghc.haskell.org/trac/ghc/ticket/12130, I'm not even able to
build the scaffolded site on GHC 8.0.1, so haven't hit this at all. Do you
have a repo this can be reproed with?

On Thu, Oct 6, 2016 at 11:57 AM, Sean Leather notifications@github.com
wrote:

@erikd https://github.com/erikd: Ah, okay. Thanks.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1284 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB51XneUkStu1V_omSVEgCcnl2bDeks5qxLfmgaJpZM4KPDu7
.

Member

snoyberg commented Oct 6, 2016

Due to https://ghc.haskell.org/trac/ghc/ticket/12130, I'm not even able to
build the scaffolded site on GHC 8.0.1, so haven't hit this at all. Do you
have a repo this can be reproed with?

On Thu, Oct 6, 2016 at 11:57 AM, Sean Leather notifications@github.com
wrote:

@erikd https://github.com/erikd: Ah, okay. Thanks.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1284 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB51XneUkStu1V_omSVEgCcnl2bDeks5qxLfmgaJpZM4KPDu7
.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

@snoyberg:

Due to https://ghc.haskell.org/trac/ghc/ticket/12130, I'm not even able to build the scaffolded site on GHC 8.0.1, so haven't hit this at all.

I ran into that one, too. For each module where the error occurred, I added:

{-# LANGUAGE NoDisambiguateRecordFields #-}
{-# LANGUAGE NoRecordWildCards #-}

and removed all uses of record wildcards in that module. That seems to have fixed the compilation errors.

Do you have a repo this can be reproed with?

Unfortunately, no. It's a large proprietary app.

Also, my rebuild just completed after rm -rf .stack-work. The problem still exists.

spl commented Oct 6, 2016

@snoyberg:

Due to https://ghc.haskell.org/trac/ghc/ticket/12130, I'm not even able to build the scaffolded site on GHC 8.0.1, so haven't hit this at all.

I ran into that one, too. For each module where the error occurred, I added:

{-# LANGUAGE NoDisambiguateRecordFields #-}
{-# LANGUAGE NoRecordWildCards #-}

and removed all uses of record wildcards in that module. That seems to have fixed the compilation errors.

Do you have a repo this can be reproed with?

Unfortunately, no. It's a large proprietary app.

Also, my rebuild just completed after rm -rf .stack-work. The problem still exists.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

OK, those language pragmas fix the issue with GHC 8, I can try to repro this.

It's tempting to remove the cabal-install dependency right now too.

Member

snoyberg commented Oct 6, 2016

OK, those language pragmas fix the issue with GHC 8, I can try to repro this.

It's tempting to remove the cabal-install dependency right now too.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

Apparently the -package-id is no longer main, but would instead need to be something like scaffold-0.0.0-7HrhUjYJCUj9s1CVz0vsT8. I don't know why this changed.

Member

snoyberg commented Oct 6, 2016

Apparently the -package-id is no longer main, but would instead need to be something like scaffold-0.0.0-7HrhUjYJCUj9s1CVz0vsT8. I don't know why this changed.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

@snoyberg:

Apparently the -package-id is no longer main, but would instead need to be something like scaffold-0.0.0-7HrhUjYJCUj9s1CVz0vsT8.

Yep, that's what I would expect, too.

spl commented Oct 6, 2016

@snoyberg:

Apparently the -package-id is no longer main, but would instead need to be something like scaffold-0.0.0-7HrhUjYJCUj9s1CVz0vsT8.

Yep, that's what I would expect, too.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

@erikd It appears that the usage of unitIdString here isn't giving us the data we need. Do you have any idea if a function like packageKeyString :: UnitId -> String still exists in GHC 8.0?

Member

snoyberg commented Oct 6, 2016

@erikd It appears that the usage of unitIdString here isn't giving us the data we need. Do you have any idea if a function like packageKeyString :: UnitId -> String still exists in GHC 8.0?

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

https://github.com/ghc/ghc/blob/ca8c0e279a87d93c1fb10460c24ef35a9080238f/compiler/basicTypes/Module.hs#L169-L173 :

-- PackageKey: This is what we used to call UnitId.  We ditched
-- "Package" from the name when we realized that you might want to
-- assign different "PackageKeys" to components from the same package.
-- (For a brief, non-released period of time, we also called these
-- UnitKeys).

spl commented Oct 6, 2016

https://github.com/ghc/ghc/blob/ca8c0e279a87d93c1fb10460c24ef35a9080238f/compiler/basicTypes/Module.hs#L169-L173 :

-- PackageKey: This is what we used to call UnitId.  We ditched
-- "Package" from the name when we realized that you might want to
-- assign different "PackageKeys" to components from the same package.
-- (For a brief, non-released period of time, we also called these
-- UnitKeys).
@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/main/Packages.hs#L1458-L1461 :

unitIdPackageIdString :: DynFlags -> UnitId -> Maybe String
unitIdPackageIdString dflags pkg_key
    | pkg_key == mainUnitId = Just "main"
    | otherwise = fmap sourcePackageIdString (lookupPackage dflags pkg_key)

Perhaps that is where the "main" is coming from?

spl commented Oct 6, 2016

https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/main/Packages.hs#L1458-L1461 :

unitIdPackageIdString :: DynFlags -> UnitId -> Maybe String
unitIdPackageIdString dflags pkg_key
    | pkg_key == mainUnitId = Just "main"
    | otherwise = fmap sourcePackageIdString (lookupPackage dflags pkg_key)

Perhaps that is where the "main" is coming from?

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

Ooh, that's promising.

Member

snoyberg commented Oct 6, 2016

Ooh, that's promising.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl commented Oct 6, 2016

And here unitIdPackageIdString is used for pretty-printing in Module.hs:

https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/basicTypes/Module.hs#L423-L431

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/basicTypes/Module.hs#L493-L496 :

-- | This is the package Id for the current program.  It is the default
-- package Id if you don't specify a package name.  We don't add this prefix
-- to symbol names, since there can be only one main package per program.
mainUnitId      = fsToUnitId (fsLit "main")

spl commented Oct 6, 2016

https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/basicTypes/Module.hs#L493-L496 :

-- | This is the package Id for the current program.  It is the default
-- package Id if you don't specify a package name.  We don't add this prefix
-- to symbol names, since there can be only one main package per program.
mainUnitId      = fsToUnitId (fsLit "main")

@snoyberg snoyberg self-assigned this Oct 6, 2016

@snoyberg snoyberg added the in progress label Oct 6, 2016

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

It seems like it might be possible to just leave off this main argument entirely and get this to work, though I'm not sure why. I'm having success on my machine at least. @spl could you try out 69f0711 from the 1284-yesod-bin-ghc-8 branch?

Member

snoyberg commented Oct 6, 2016

It seems like it might be possible to just leave off this main argument entirely and get this to work, though I'm not sure why. I'm having success on my machine at least. @spl could you try out 69f0711 from the 1284-yesod-bin-ghc-8 branch?

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

@snoyberg: Yep, that works here.

Could it be that it's able to find the other modules in the main package somehow?

spl commented Oct 6, 2016

@snoyberg: Yep, that works here.

Could it be that it's able to find the other modules in the main package somehow?

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 6, 2016

Member

I just realized that -hide-all-packages isn't turned on, which would explain it. In reality, given a Stack use case, almost all of this complication around getting the right set of packages is unnecessary, since Stack will provide a consistent package set in the databases. This really is agitating towards a massive simplification of yesod devel to take advantage of this, but perhaps for now simply releasing the small change I made makes sense.

Member

snoyberg commented Oct 6, 2016

I just realized that -hide-all-packages isn't turned on, which would explain it. In reality, given a Stack use case, almost all of this complication around getting the right set of packages is unnecessary, since Stack will provide a consistent package set in the databases. This really is agitating towards a massive simplification of yesod devel to take advantage of this, but perhaps for now simply releasing the small change I made makes sense.

@spl

This comment has been minimized.

Show comment
Hide comment
@spl

spl Oct 6, 2016

Agreed. Thank you very much for your help.

spl commented Oct 6, 2016

Agreed. Thank you very much for your help.

@snoyberg snoyberg closed this in 1753569 Oct 6, 2016

@snoyberg snoyberg removed the in progress label Oct 6, 2016

@vandenoever

This comment has been minimized.

Show comment
Hide comment
@vandenoever

vandenoever Oct 7, 2016

I'm seeing this issue with ghc 8.0.1, cabal 1.24.0.0 and yesod-bin 1.4.18.6.
The server that shows "The application isn’t built" is started, but after building <command line>: cannot satisfy -package-id main' is shown.

The commandline for runghc ends with -package-idmain app/devel.hs. (shown by yesod devel -v).

The runghc command can be run by hand without the -package-idmain, however this exits immediately.

vandenoever commented Oct 7, 2016

I'm seeing this issue with ghc 8.0.1, cabal 1.24.0.0 and yesod-bin 1.4.18.6.
The server that shows "The application isn’t built" is started, but after building <command line>: cannot satisfy -package-id main' is shown.

The commandline for runghc ends with -package-idmain app/devel.hs. (shown by yesod devel -v).

The runghc command can be run by hand without the -package-idmain, however this exits immediately.

@vandenoever

This comment has been minimized.

Show comment
Hide comment
@vandenoever

vandenoever Oct 7, 2016

It looks like 1284-yesod-bin-ghc-8 was not merged.

vandenoever commented Oct 7, 2016

It looks like 1284-yesod-bin-ghc-8 was not merged.

snoyberg added a commit that referenced this issue Oct 7, 2016

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 7, 2016

Member

Doh, good catch. Hopefully 1.4.18.7 should do it.

On Fri, Oct 7, 2016 at 5:02 PM, Jos van den Oever notifications@github.com
wrote:

It looks like 1284-yesod-bin-ghc-8 was not merged.


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1284 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB7kRmZmDYH-VGKYPl03WMxYaIZitks5qxlD3gaJpZM4KPDu7
.

Member

snoyberg commented Oct 7, 2016

Doh, good catch. Hopefully 1.4.18.7 should do it.

On Fri, Oct 7, 2016 at 5:02 PM, Jos van den Oever notifications@github.com
wrote:

It looks like 1284-yesod-bin-ghc-8 was not merged.


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1284 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB7kRmZmDYH-VGKYPl03WMxYaIZitks5qxlD3gaJpZM4KPDu7
.

@vandenoever

This comment has been minimized.

Show comment
Hide comment
@vandenoever

vandenoever Oct 7, 2016

Yep, now it's fixed. Thanks!

vandenoever commented Oct 7, 2016

Yep, now it's fixed. Thanks!

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Nov 23, 2016

Member

People here may be interested in this commit:

83d3a12

and this comment:

#1304 (comment)

Member

snoyberg commented Nov 23, 2016

People here may be interested in this commit:

83d3a12

and this comment:

#1304 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment