External hackages #535
External hackages #535
Conversation
|
The first two commits belong in a separate PR. They have nothing to do with hackage repositories. |
|
Do you think I should point this PR to a branch without those commits? |
|
Do you think I should point this PR to a branch without those commits?
I believe you should do that.
|
maksbotan
force-pushed
the
external-hackages
branch
from
07acc06 to
a1a1cdf
Compare
|
Done! |
|
Otherwise, LGTM (if it works, I haven't tested it yet) |
|
This seems like a slightly unusual usecase, so I think this could really do with a test to make sure it keeps working! |
|
How do I make a test in this repo? |
|
Pending a test, this LGTM. |
|
@angerman thanks, I'll add a test :) |
|
@maksbotan this seems somewhat stale pending a test, could we get this done and merge it? |
|
I've wanted the |
|
@angerman sorry! I was planning to work on this today and tomorrow, so expect tests to be done :) |
|
@maksbotan awesome! Looking forward to it! |
Currently haskell.nix is not able to build Cabal projects that depend on packages from private Hackage repositories, as it make only main Hackage available to cabal. This is unfortunate. This commit adds this functionality, by allowing the user to pass `extra-hackages` and `extra-hackage-tarballs` to `mkPkgSet` and `callCabalToNix` respectively, to add as much extra repositories as needed. This repositories are first made available to Cabal when calling `v2-configure`, resulting in correct plans. Later they are combined with global Hackage when building dependencies of the local packages.
Currently callCabalProjectToNix does not copy `cabal.project.freeze` from source directory, leading to different build plans when building components with nix and when building project with `cabal new-build` inside `nix-shell`. This behavior is undesired, so this commits fixes it.
maksbotan
force-pushed
the
external-hackages
branch
from
a1a1cdf to
75db8c4
Compare
|
@angerman so, here are tests. I hope I did everything right :) Do you have some kind of CI here to actually run them? |
|
Oh, and I remind that this PR depends on input-output-hk/nix-tools#84. It would be nice to have |
maksbotan
force-pushed
the
external-hackages
branch
from
75db8c4 to
e7a6a80
Compare
Add test execution logic
|
No idea why CI isn't picking this up. hydra link |
This change builds #535. `repository` blocks in `cabal.project` parsed and `cabal` is used to automatically downloaded them. Then `hackage-to-nix` is used to produce the nix required. To make it work with restricted eval (on hydra for instance) we need to include a sha256 like this: ``` repository ghcjs-overlay url: https://input-output-hk.github.io/hackage-overlay-ghcjs secure: True root-keys: key-threshold: 0 --sha256: sha256-EPlLYPmIGtxeahlOspRzwJv+60N5mqrNC2BY4jZKceE= ``` To find the correct `sha256` put in an invalid one and attempt a build.
* Improve support for external Hackage repositories This change builds #535. `repository` blocks in `cabal.project` parsed and `cabal` is used to automatically downloaded them. Then `hackage-to-nix` is used to produce the nix required. To make it work with restricted eval (on hydra for instance) we need to include a sha256 like this: ``` repository ghcjs-overlay url: https://input-output-hk.github.io/hackage-overlay-ghcjs secure: True root-keys: key-threshold: 0 --sha256: sha256-EPlLYPmIGtxeahlOspRzwJv+60N5mqrNC2BY4jZKceE= ``` To find the correct `sha256` put in an invalid one and attempt a build.
Two changes:
This branch also includes serokell/kirelagin/darwin-so because I needed fixes from #534 .
Support for external hackages requires this PR: input-output-hk/nix-tools#84