`cabal list-bin` too sensitive to configuration?

[andreasabel]

Is cabal list-bin too sensitive to configuration?
It requires me to pass the same flags as to build. In contrast, cabal-plan list-bin does not require this.
(Example project taken from https://github.com/asr/pdfname.)

/pdfname$ cabal build --allow-newer=pdfname:base
(succeeds)

/pdfname$ cabal-plan list-bin pdfname
(succeeds)

/pdfname$ cabal list-bin pdfname
(after a 2 sec wait, fails)
Error: cabal: Could not resolve dependencies...

/pdfname$ cabal list-bin pdfname --allow-newer=pdfname:base
(succeeds)

I wonder whether list-bin could be more robust wrt. missing flags. Some flags do matter to find the correct executable (like -w), but some won't (like --allow-newer).

[phadej]

list-bin is indeed reconfigures. Consider:

cabal build --constraint='aeson <2'
cabal list-bin my-test --constraint='aeson >=2'

What should happen here? With cabal-plan this example doesn't make sense: cabal-plan list-bin doesn't take any solver related flags.

An option is to make cabal list-bin behave like cabal-plan list-bin, i.e don't take any configuration options and load the last one used. When list-bin was implemented there weren't machinery for the latter though: it's a (Rebuild monad)
"build-system" without such a feature: there wasn't a way to run it so it only loads caches, but doesn't (re)build. That feature would be very welcome.

[fgaz]

If the code doesn't get too unwieldy it could be an option, eg. --cached

[andreabedini]

Looping myself in for future reference