Unable to do `cabal repl` in `nix develop`

[MaximilianAlgehed]

I'm unable to get a repl in nix develop due to a bug in cabal in combination with the -wunsed-packages and -werror flags on master:

[nix-shell:~/IOHK/cardano-ledger]$ cabal repl cardano-ledger-test
Build profile: -w ghc-9.2.8 -O1
In order, the following will be built (use -v for more details):
 - cardano-ledger-test-9.9.9.9 (lib) (first run)
Preprocessing library for cardano-ledger-test-9.9.9.9..
GHCi, version 9.2.8: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/max/.ghci
*** Exception: The following packages were specified via -package or -package-id flags
,
but were not needed for compilation:
  - vector-map-1.1.0.0-inplace
  - vector-0.13.1.0-1givoIbXaW8EKkPAEGUdwN
  - unordered-containers-0.2.19.1-AZgqrMMLwfMo8gCOwLaCz
  - transformers-0.5.6.2-9dB7NoP3DN96foOHFGxrBI
  - time-1.11.1.1-3c78rVb4UjbAw9ujAnKmhM
  - text-1.2.5.0-Ii1ClGOyJQ8AmHgulTPR3f
  - tasty-quickcheck-0.10.3-Aw1cSsenL7GA9VTAmvA219
  - tasty-hunit-0.10.1-4bLJnR6VySV1ZwaXiMzc8c
  - tasty-1.5-3nSWSjVPiSX42AUr2ppSmU
  - small-steps-test-1.0.1.0-inplace
  - small-steps-1.0.1.0-inplace
  - set-algebra-1.1.0.2-inplace
  - prettyprinter-1.7.1-JaBlLOwE9EL3UvtjhFKd8F
  - plutus-ledger-api-1.21.0.0-96327e4d49107551dd74e44d4db1d6f2ed335e79a4f5019cb4fb80d
254444b71
  - nothunks-0.1.5-J5ciWRVBQB9JY7BHDmaoO1
  - mtl-2.2.2-EQmIEUm7Isr3UTWxMseEok
  - microlens-0.4.13.1-HPplyG5VOciEIF62YegSgA
  - hspec-2.11.7-BEAffxSogQDDlJ99ZbWqq
  - haskeline-0.8.2-4i6iiPbxUKxJXcHFEML7p4
  - hashable-1.4.3.0-HdDIjbBu0mpEb1E8AVwbk
  - groups-0.5.3-He77FKRfptY37aszXu6pZX
  - formatting-7.2.0-LSVefFfvA9GKj81K0dCtRc
  - deepseq-1.4.6.1
  - data-default-class-0.1.2.0-LTHfZ727qQNBDQWXr7ndfO
  - cryptonite-0.30-5BfL5RvKYXkA3yAUcH0tS5
  - containers-0.6.5.1-LoBk5T9QwNLBqnqOQVtDCh
  - constrained-generators-0.2.0.0-inplace
  - cardano-strict-containers-0.1.2.1-CzIHPEXIoTJJJyQJjsQ9hq
  - cardano-slotting-0.1.2.0-17d3de87d2cd8e3bb79fdd5a320ff86f6f0c08ebaf15e3023e78c3fcf
e4b773c
  - cardano-protocol-tpraos-1.1.0.0-inplace-testlib
  - cardano-protocol-tpraos-1.1.0.0-inplace
  - cardano-ledger-shelley-test-1.3.0.2-inplace
  - cardano-ledger-shelley-ma-test-1.2.1.7-inplace
  - cardano-ledger-shelley-1.10.0.0-inplace-testlib
  - cardano-ledger-shelley-1.10.0.0-inplace
  - cardano-ledger-mary-1.5.1.0-inplace
  - cardano-ledger-core-1.11.0.0-inplace-testlib
  - cardano-ledger-core-1.11.0.0-inplace
  - cardano-ledger-conway-1.13.0.0-inplace-testlib
  - cardano-ledger-conway-1.13.0.0-inplace
  - cardano-ledger-byron-1.0.0.4-inplace
  - cardano-ledger-binary-1.3.0.0-inplace-testlib
  - cardano-ledger-binary-1.3.0.0-inplace
  - cardano-ledger-babbage-test-1.2.0.1-inplace
  - cardano-ledger-babbage-1.7.0.0-inplace-testlib
  - cardano-ledger-babbage-1.7.0.0-inplace
  - cardano-ledger-api-1.9.0.0-inplace
  - cardano-ledger-alonzo-test-1.2.0.1-inplace
  - cardano-ledger-alonzo-1.7.0.0-inplace-testlib
  - cardano-ledger-alonzo-1.7.0.0-inplace
  - cardano-ledger-allegra-1.4.0.0-inplace-testlib
  - cardano-ledger-allegra-1.4.0.0-inplace
  - cardano-data-1.2.1.0-inplace
  - cardano-crypto-wrapper-1.5.1.1-inplace
  - cardano-crypto-class-2.1.4.0-KyUPiiF9EuIKPzIyNfQrTl
  - cardano-crypto-1.1.2-jX90Xx6wmHBk7GKhWapOn
  - bytestring-0.11.4.0-20YrNqjxeS9FbmijR89bLb
  - bech32-1.1.4.1-EtdhVL6K3NN851saNtYh90
  - base-4.16.4.0
  - array-0.5.4.0
  - QuickCheck-2.14.3-Ck1gBujdlJR2XOeXXh0uJz

[lehins]

This is not a bug, but a local misconfiguration.

This project is configured to run on CI. Anything that is needed to be done differently for local development falls onto the developer. In this case it can be easily solved with cabal.project.local:

if impl(ghc < 9.8)
  program-options
    ghc-options: -Wwarn

[MaximilianAlgehed]

May I suggest that the right solution is to make the project easy to pick up for developers and add a ci flag to the cabal configuration?

[lehins]

May I suggest that the right solution is to make the project easy to pick up for developers and add a ci flag to the cabal configuration?

I appreciate your suggestion, but no.

Developer should be aware of cabal configure stage of the build process.

With respect to this issue, it is a workaround and the real bug is in cabal+ghc. Those warnings should not be emitted to begin with.

[MaximilianAlgehed]

@lehins I don't understand your philosophy, here you don't want to work around a bug in the tools in a way that wouldn't create much of an overhead in the source code. But when it comes to langauge extensions in cabal files, the philosophy is to work around the bug in stack in a way that adds lots of overhead to all the source code?

[lehins]

@MaximilianAlgehed I took your suggestion into consideration and I said no. Your job is not to understand my philosophy, but to adhere to the development rules that have been established. If you have a problem with this, please let me know.

[MaximilianAlgehed]

I'm just trying to understand what the rules are and why... Understanding the reasoning (if there is one) behind why things are done one way or another is the key to working effectively and improving the things that can be improved and working around the things that need to be worked around.

Apparently this is a touchy subject. Is the rationale behind decisions documented anywhere? That would make it easier to understand what's going on.