v2-exec does not work properly without using v2-build first

[int-e]

Describe the bug
The v2-exec subcommand does not work properly if one has not used v2-build first, because it makes assumptions about the layout of the dist-newstyle directory. In particular,

• it assumes that a directory dist-newstyle/tmp exists; and
• it assumes that there is an initialized package database at dist-newstyle/packagedb/$compiler.

To Reproduce
Steps to reproduce the behavior:

$ cd $(mktemp -d)
$ cabal unpack acme-dont-1.1
$ echo 'packages: acme-dont-1.1' > cabal.project
$ cabal v2-install acme-dont
$ cabal v2-exec ghci
Resolving dependencies...
/tmp/.../dist-newstyle/tmp/environment.-24158: createDirectory: does not exist (No such file or directory)
$ mkdir dist-newstyle/tmp
$ cabal v2-exec ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
Loaded package environment from /tmp/.../dist-newstyle/tmp/environment.-24973/.ghc.environment.x86_64-linux-8.6.5
ghc: can't find a package database at /tmp/.../dist-newstyle/packagedb/ghc-8.6.5
$ ghc-pkg init dist-newstyle/packagedb/ghc-8.6.5
$ cabal v2-exec ghci
(finally works)

Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.

Expected behavior
I expect the first cabal v2-exec ghci to work, ideally even without running v2-install first.

System informataion

$ uname -a 
Linux harpy 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
$ cabal --version
cabal-install version 2.4.1.0
compiled using version 2.4.1.0 of the Cabal library 
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5

Additional context
This came up while trying to replicate my lambdabot development process (which is currently based on a sandbox) with v2-* tools. Notes:

• v2-repl will not help in my actual use case because instead of ghci I'd be running lambdabot and need an environment setup for mueval to find the installed libraries.
• I intend to use v2-install rather than v2-build because I'll be installing to a project-local store anyway, simulating a sandbox. I believe using v2-install makes it easier (compared to v2-build) to get all the executables into one place.

[ChristopherKing42]

I suppose a workaround for this is to alias "cabal new-exec" to "cabal new-build; cabal new-exec".

[fgaz]

Didn't v1-exec assume a built package too?

[ChristopherKing42]

Hmm, if this is the intended behavior, maybe at least raise a warning like "warning: your build is not up to date".

[int-e]

Didn't v1-exec assume a built package too?

1. I don't think so, at least not for sandboxes:

$ cabal v1-sandbox init
[...]
Creating a new sandbox at [...]/.cabal-sandbox
$ cabal v1-exec ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
Prelude>

2. I actually built a package (namely, acme-dont) before using v2-exec. I didn't use v2-build for that though, I used v2-install.

3. With cabal-install 3.0.0.0, the v2-install command already fails:

$ cabal --version
cabal-install version 3.0.0.0
compiled using version 3.0.0.0 of the Cabal library 
$ cd $(mktemp -d)
$  cabal unpack acme-dont-1.1
$ echo 'packages: acme-dont-1.1' > cabal.project
$ cabal v2-install acme-dont
Wrote tarball sdist to
/tmp/tmp.MUhu170sGX/dist-newstyle/sdist/acme-dont-1.1.tar.gz
Resolving dependencies...
cabal3.0.0.0: Cannot build the executables in the package acme-dont because it
does not contain any executables. Check the .cabal file for the package and
make sure that it properly declares the components that you expect.

4. Everything works if I use cabal v2-build acme-dont instead of the v2-install line, both with version 2.4.1.0 and with version 3.0.0.0. So what exactly are the roles of v2-install and v2-build? Shouldn't the former do everything a v2-build does, and additionally take care of symlinking executables?