haskell builder: don't copy packages from GHCs #57706
Closed
+229
−64
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This update was generated by hackage2nix v2.14.2 from Hackage revision commercialhaskell/all-cabal-hashes@accf2e4.
This update was generated by hackage2nix v2.14.2 from Hackage revision commercialhaskell/all-cabal-hashes@cc9fd95.
In order to build the package databases that we will use when compiling a Haskell package, we iterate over the relevant dependencies, and if they contain a package db, we copy its contents over. So far so good, except when one of those dependencies is GHC. This doesn't happen ordinarily, but it will happen when we construct the package database for compiling `Setup.hs`. This is compiled for the build architecture, so we get the build deps, including both the native and the cross GHC (if there is one). In this case, we end up copying the packages from the GHC's package database. This is at best unnecessary, since we will get those packages from the GHC when we compile with it. At worst, however, this is semantically questionable. We can end up having multiple copies of e.g. Cabal with the same version, but (potentially) different contents. At the moment, GHC will expose one of these at semi-random depending on which one it looks at "first". However, there is a MR open [in GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a side effect will instead expose both, leading to ambiguous module warnings (which is not unreasonable, since it *is* ambiguous). So what can we do about it? The simplest solution is just to not copy the package databases from GHC. GHC is special in this regard, so I think it's okay to treat it specially. This PR should have no effect on anything now, but will prevent any breakage when/if the GHC patch lands.
peti
force-pushed
the
haskell-updates
branch
5 times, most recently
from
2125549 to
6a6450b
Compare
|
I use |
peti
reviewed
Mar 16, 2019
peti
pushed a commit
that referenced
this pull request
Mar 16, 2019
In order to build the package databases that we will use when compiling a Haskell package, we iterate over the relevant dependencies, and if they contain a package db, we copy its contents over. So far so good, except when one of those dependencies is GHC. This doesn't happen ordinarily, but it will happen when we construct the package database for compiling `Setup.hs`. This is compiled for the build architecture, so we get the build deps, including both the native and the cross GHC (if there is one). In this case, we end up copying the packages from the GHC's package database. This is at best unnecessary, since we will get those packages from the GHC when we compile with it. At worst, however, this is semantically questionable. We can end up having multiple copies of e.g. Cabal with the same version, but (potentially) different contents. At the moment, GHC will expose one of these at semi-random depending on which one it looks at "first". However, there is a MR open [in GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a side effect will instead expose both, leading to ambiguous module warnings (which is not unreasonable, since it *is* ambiguous). So what can we do about it? The simplest solution is just to not copy the package databases from GHC. GHC is special in this regard, so I think it's okay to treat it specially. This PR should have no effect on anything now, but will prevent any breakage when/if the GHC patch lands. Closes #57706.
|
Merged to |
|
Thanks! |
|
I'm not sure I quite followed the workflow process there, but I'd appreciate it if this got into |
peti
pushed a commit
that referenced
this pull request
Mar 18, 2019
In order to build the package databases that we will use when compiling a Haskell package, we iterate over the relevant dependencies, and if they contain a package db, we copy its contents over. So far so good, except when one of those dependencies is GHC. This doesn't happen ordinarily, but it will happen when we construct the package database for compiling `Setup.hs`. This is compiled for the build architecture, so we get the build deps, including both the native and the cross GHC (if there is one). In this case, we end up copying the packages from the GHC's package database. This is at best unnecessary, since we will get those packages from the GHC when we compile with it. At worst, however, this is semantically questionable. We can end up having multiple copies of e.g. Cabal with the same version, but (potentially) different contents. At the moment, GHC will expose one of these at semi-random depending on which one it looks at "first". However, there is a MR open [in GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a side effect will instead expose both, leading to ambiguous module warnings (which is not unreasonable, since it *is* ambiguous). So what can we do about it? The simplest solution is just to not copy the package databases from GHC. GHC is special in this regard, so I think it's okay to treat it specially. This PR should have no effect on anything now, but will prevent any breakage when/if the GHC patch lands. Closes #57706. (cherry picked from commit 387c513)
michaelpj
added a commit
to input-output-hk/nixpkgs
that referenced
this pull request
Mar 18, 2019
In order to build the package databases that we will use when compiling a Haskell package, we iterate over the relevant dependencies, and if they contain a package db, we copy its contents over. So far so good, except when one of those dependencies is GHC. This doesn't happen ordinarily, but it will happen when we construct the package database for compiling `Setup.hs`. This is compiled for the build architecture, so we get the build deps, including both the native and the cross GHC (if there is one). In this case, we end up copying the packages from the GHC's package database. This is at best unnecessary, since we will get those packages from the GHC when we compile with it. At worst, however, this is semantically questionable. We can end up having multiple copies of e.g. Cabal with the same version, but (potentially) different contents. At the moment, GHC will expose one of these at semi-random depending on which one it looks at "first". However, there is a MR open [in GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a side effect will instead expose both, leading to ambiguous module warnings (which is not unreasonable, since it *is* ambiguous). So what can we do about it? The simplest solution is just to not copy the package databases from GHC. GHC is special in this regard, so I think it's okay to treat it specially. This PR should have no effect on anything now, but will prevent any breakage when/if the GHC patch lands. Closes NixOS#57706.
angerman
pushed a commit
to input-output-hk/nixpkgs
that referenced
this pull request
Mar 18, 2019
In order to build the package databases that we will use when compiling a Haskell package, we iterate over the relevant dependencies, and if they contain a package db, we copy its contents over. So far so good, except when one of those dependencies is GHC. This doesn't happen ordinarily, but it will happen when we construct the package database for compiling `Setup.hs`. This is compiled for the build architecture, so we get the build deps, including both the native and the cross GHC (if there is one). In this case, we end up copying the packages from the GHC's package database. This is at best unnecessary, since we will get those packages from the GHC when we compile with it. At worst, however, this is semantically questionable. We can end up having multiple copies of e.g. Cabal with the same version, but (potentially) different contents. At the moment, GHC will expose one of these at semi-random depending on which one it looks at "first". However, there is a MR open [in GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a side effect will instead expose both, leading to ambiguous module warnings (which is not unreasonable, since it *is* ambiguous). So what can we do about it? The simplest solution is just to not copy the package databases from GHC. GHC is special in this regard, so I think it's okay to treat it specially. This PR should have no effect on anything now, but will prevent any breakage when/if the GHC patch lands. Closes NixOS#57706.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to build the package databases that we will use when compiling
a Haskell package, we iterate over the relevant dependencies, and if
they contain a package db, we copy its contents over.
So far so good, except when one of those dependencies is GHC. This
doesn't happen ordinarily, but it will happen when we construct the
package database for compiling
Setup.hs. This is compiled for thebuild architecture, so we get the build deps, including both the native
and the cross GHC (if there is one).
In this case, we end up copying the packages from the GHC's package
database. This is at best unnecessary, since we will get those packages
from the GHC when we compile with it.
At worst, however, this is semantically questionable. We can end up
having multiple copies of e.g. Cabal with the same version, but
(potentially) different contents. At the moment, GHC will expose one of
these at semi-random depending on which one it looks at "first".
However, there is a MR open in GHC which as a
side effect will instead expose both, leading to ambiguous module
warnings (which is not unreasonable, since it is ambiguous).
So what can we do about it? The simplest solution is just to not copy
the package databases from GHC. GHC is special in this regard, so I
think it's okay to treat it specially.
This PR should have no effect on anything now, but will prevent any
breakage when/if the GHC patch lands.
I've opened this against
haskell-updates- or should it bestaging?I've tested this by building our packages that use the nixpkgs Haskell infrastructure, using this patch and a GHC patched with the change in the linked MR. That builds and works fine on NixOS and macOS.
Motivation for this change
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)