v2-exec skips inplace package-ids for explicit compiler versions

[tseenshe]

Describe the bug

In a very simple cabal project (any "hello world" style project) I observe the following

$ cabal v2-exec -w ghc-8.4.4 -v0 -- bash -c 'cat $GHC_ENVIRONMENT' > env.ghc-8.4.4
$ cabal v2-exec -w ghc -v0 -- bash -c 'cat $GHC_ENVIRONMENT' > env.ghc
$ diff env.ghc env.ghc-8.4.4 
11d10
< package-id medley-0.0.1-inplace

namely the v2-exec generated environment file is different depending on if I provide a specifically named ghc or the system default. In fact -w ghc may be omitted and the same is observed.

Of course, I expect them to be the same! It seems that the provision of a specific version of ghc rather than my system default is causing the env file to be broken.

A consequence is that tooling launched with v2-exec and a specific compiler version is broken.

System informataion

$ 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.4.4

If I alternate between cabal v2-build -w ghc and cabal v2-build -w ghc-8.4.4 before the commands above, then it flips the results!

To eliminate the noise from the project-generated env file I have tried this with

write-ghc-environment-files: never

but it makes no difference.

In addition, if I use with-compiler: ghc-8.4.4 in the cabal.project, then the -w ghc run is the broken one.

So I think there is definitely something funny going on with custom, explicit, compilers.

[tseenshe]

ok, I have seen even weirder behaviour, now the -O0 is interfering!

Automated test:

https://gitlab.com/tseenshe/hsinspect/tree/27cf9acef6be15c8b6e825ec9a8be10bd2dc17b2/

running ./tests.sh the outputted tests/medley/env.ghc-8.4.4 does not have the -inplace in it, but it should be there. You can comment out the final find from that script as we're not concerned with the actual tests, but the env that the command is running within.

Or in descriptive terms:

1. cabal v2-build -O0 -w ghc-8.4.4
2. cabal v2-exec -- sh -c 'cat $GHC_ENVIRONMENT' > env

then the env is broken

[tseenshe]

Hmm, is it possible that any explicit change in the -w or -O leves in the v2-build will skip local packages from the .ghc.env? That's very unfortunate because a common workflow is that developers will want to compile with -O0. If some tooling then runs (e.g. editor tooling that is automatically run regardless of context, such as my hsindent) it will not have access to the newly created .hi files.

It would be good if there was a mode of operation of v2-exec such that it sees the most recently created packagedb for local projects.

[tseenshe]

Adding --enable-tests to cabal v2-build also seems to cause the env file to be missing the package deps 😞

[tseenshe]

and if any of the source files in the package are stale then the inplace is also missing... 😞

[tseenshe]

I'm starting to think that I'm expecting too much from v2-exec.

What I need is a command that conjures the last env file that was built. I want to be able to support users who disable the env files with

write-ghc-environment-files: never

and especially since they are going to be disabled by default soon (I heard?).

[DanielG]

Have you tried cabal v2-build --dry-run? I'm not sure if it writes env files, but it sure regenerates plan.json so I don't see why it wouldn't also do the envs.

[23Skidoo]

IIRC an env file is written out only after a build has succeeded (i.e. --dry-run doesn't cause an env file to be written).

[tseenshe]

Have you tried cabal v2-build --dry-run? I'm not sure if it writes env files, but it sure regenerates plan.json so I don't see why it wouldn't also do the envs.

@DanielG nice idea! But the workflow is such that the user would be doing the build, and I would be invoking my command automatically from the text editor without knowing which options they used (maybe they used the command line to do it) so I really just want access to the env file that corresponds to the last compile. I thought v2-exec was doing this, but evidently not. I suppose it's good that it separates the PATH because you might have build several versions of a binary and want to invoke the correct one, but for the env file it is less clear... so perhaps a flag to v2-exec could clear it up. e.g. v2-exec --most-recent-envfile -- hsinspect.

[tseenshe]

BTW here is a demo of when my tool is working 😄 to give you an idea of what I want to achieve

https://twitter.com/ts33nsh3/status/1159513161726386176

[phadej]

Read `plan.json` (check cabal-plan package) and construct env from it. Trying to do the same with shell magic is too much asked from cabal-install.

…

On 8 Aug 2019, at 20.43, Tseen She ***@***.***> wrote: BTW here is a demo of when my tool is working 😄 to give you an idea of what I want to achieve https://twitter.com/ts33nsh3/status/1159513161726386176 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[DanielG]

I think what you want to do is use the cabal-plan library and read the info you need from plan.json which should have everything you need.

I take it you're using the GHC library but only accessing package-db stuff? Otherwise I'd reccommend you have a look at my cabal-helper library for tooling use-cases though the v2-build support is still a bit WIP.

[tseenshe]

@DanielG indeed I have a TODO note to use cabal-helper! I wanted to have a clear idea of which features I needed before bugging you about it 😄 I am also interested in hie-bios (eventually) but I am scared to add any dependencies because it complicates the installation process for end users. I still have many deployment and user-information gathering problems yet to solve. Where should we move that conversation to? Problems I have include: lauching correct version of my app for ghc version, finding users language/extensions/flags per package (and phase within that package), finding packagedb (ideally for the correct phase and package not just brute force like the cabal env file).

@phadej it looks like cabal-helper is the only option. I think v2-exec is ultimately not the right tool for the problem I am trying to solve.