new-run should cd to the package directory before running the exe

[fgaz]

Most exes(tests,benchs) expect to be run in the package root, but with the introduction of projects this is no longer always true.

This became evident when trying new-run with the cabal-install tests (using #4861) while being in the project root.

Relevant lines:

cabal/cabal-install/Distribution/Client/CmdRun.hs

Lines 214 to 218 in 0122cf2

	emptyProgramInvocation {
	progInvokePath = exePath,
	progInvokeArgs = args,
	progInvokeEnv = dataDirsEnvironmentForPlan elaboratedPlan
	}

[hvr]

Please don't! I rely in almost all my uses of new-run of not changing the CWD

for example, I've got lots of shell wrappers in my $PATH which look e.g. like

#!/bin/sh -e

#SCRIPTPATH="$( cd "$(dirname "$0")" ; pwd -P )"
SCRIPTPATH=/home/hvr/work/GitHub/cabal-plan
EXENAME="exe:$(basename "$0")"

exec cabal new-run -v0 --project-file "$SCRIPTPATH/cabal.project" "$EXENAME" -- "$@"

and which rely on the caller's CWD to remain unaffected.

[angerman]

Where ever this goes, let us please reduce changes to CWD rather than add even more. To stop hacking around this with hadrian and ghc, I had to start working on #4874, which tries to do exactly the opposite and stop relying on the CWD.

After all the CWD is some ugly global state. I'm convinced we should try to reduce touching it to the very bare minimum we can. It is also to my understanding the reason cabal has to shell out and call itself for parallel builds, due to the messy global CWD state.

[fgaz]

What about the cabal tests then? Should they get the test directory as an argument? Should we add the test directory as a datadir?

(i'm not arguing against not touching CWD, I agree with that too)

edit: to reproduce:

$ cd cabal-repo-root
$ cabal-#4874 new-run cabal-install:integration-tests2

[hvr]

@fgaz test/benchmarks are a bit of a special case; some random ideas: have a --set-cwd flag for new-run; or alternatively, set some env-vars like CABAL_PROJECT_ROOT and CABAL_PACKAGE_ROOT or maybe others...

[23Skidoo]

I'd prefer to not add more env vars affecting cabal-install's behaviour, because, as Zen of Python tells us, explicit is better than implicit.

[hvr]

@23Skidoo yeah, but how to do we communicate with an exitcode-stdio type benchmark/test-suite if we need to tell it locations or other meta-information of its environment (which is something we're gonna need)?

[ta0kira]

I agree with #5001 (comment). I had a bug for a week or so that went unnoticed by my CI because the path used by getDataFileName was "coincidentally" the same as $PWD. (I was running my tests from the package path and my code had a bug where it was effectively always using $PWD instead of the data path.)

I wasn't previously aware that I could fix my testing with cd and --project-file. If run did a cd then I don't know how I'd be testing that my code uses getDataFileName in the correct places.

[fgaz]

I guess this can be closed? The tests still fail if not ran from within the package directory, but that's a separate issue