Shell.nix, almost

[deepfire]

This almost brings back nix-shell that can build/run demo-playground.

The only blocker is the need to remove the source package definitions in the Cabal project file, which is caused by this Cabal issue: haskell/cabal#6049 (comment)

[nc6]

This doesn't seem to work for me (whereas the previous iteration did):

[nc@lorien:~/topos/iohk/ouroboros-network]$ nix-shell --run "cabal new-build ouroboros-consensus"
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: cardano-crypto-wrapper-1.3.0 (user goal)
[__1] trying: base64-bytestring-type-1.0.1/installed-Hpj... (dependency of
cardano-crypto-wrapper)
[__2] next goal: serialise (dependency of base64-bytestring-type)
[__2] rejecting: serialise-0.2.1.0/installed-LOU... (package is broken)
[__2] fail (backjumping, conflict set: base64-bytestring-type, serialise)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base64-bytestring-type,
cardano-crypto-wrapper, serialise

[deepfire]

@nc6, two options for what could have gone wrong:

1. GHC environment file -- remedy being rm .ghc.environment.*
2. source-repository-package in cabal.project (problematic as mentioned) -- remedy being commenting out these sections, so that grep '^source-repository-package' cabal.project | wc -l is 0

(EDIT: to clarify, I couldn't reproduce locally.)

[rvl]

why not this?

Suggested change

	packages = p: map (x: p."${x}") [
	packages = ps: with ps; [ io-sim io-sim-classes ... ];
	inherit withHoogle;

[deepfire]

Good point, thanks!

[rvl]

I think it's fine to assume that the user already has the latest cabal in their profile, so we don't need to add it to the project's dependencies.

[deepfire]

Is it really? The cabal in question might be incongruent in some fashion with the GHC in use -- or even completely absent.

If we choose not to specify it here, it would be one of those extra things for someone to care (as in debug, research etc.) about.

[rvl]

This project's Haskell.nix package set is generated from stack.yaml. If the cabal.project adds slightly different version constraints, then the nix-shell is unlikely to work for cabal.

I got the same error as @nc6. If I removed the constraints and source-repository-package sections from `cabal.project then it worked.

[deepfire]

This project's Haskell.nix package set is generated from stack.yaml. If the cabal.project adds slightly different version constraints, then the nix-shell is unlikely to work for cabal.

I got the same error as @nc6. If I removed the constraints and source-repository-package sections from `cabal.project then it worked.>

@rvl, indeed. I've mentioned that in the PR description -- there is an upstream issue regarding this problem.

Do you have a suggestion of a workaround in the meantime?

[rvl]

I don't think this is an upstream issue with Cabal.

The Haskell.nix shellFor function forces Cabal, ghc and ghc-pkg into using its own package db and nothing else. So the Cabal solver doesn't have any options other than to use what it's been given.

But if cabal.project and the shellFor environment are inconsistent (i.e. contradictory), then it's going to break.

So you need to make sure that cabal.project and stack.yaml are consistent, because the shell is generated from stack.yaml. You could change from stack-to-nix to plan-to-nix, but that there's a bug that needs to be fixed first: input-output-hk/haskell.nix#182.

[deepfire]

The Haskell.nix shellFor function forces Cabal, ghc and ghc-pkg into using its own package db and nothing else.

What you just described is specifically the Cabal behavior I asked the upstream for -- and according to them, it's not currently possible -- if you have a cabal.project that contains source-repository-package references, they are going to be used by cabal-install.

[deepfire]

Closed in favor of #723 -- same, but updated.