Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack repl subpackage compile time cwd is different from stack build subpackage one #5421

Closed
jneira opened this issue Nov 2, 2020 · 6 comments · Fixed by #5448
Closed

stack repl subpackage compile time cwd is different from stack build subpackage one #5421

jneira opened this issue Nov 2, 2020 · 6 comments · Fixed by #5448

Comments

@jneira
Copy link
Contributor

jneira commented Nov 2, 2020

General summary/comments (optional)

The current working dir at compile time is different between stack build and stack repl. It likely makes template haskell io computations relying in cwd fail, cause the relative file or directory usually does not exist.
This in turn makes that code not usable in a ide (hls, ghcide) that uses hie-bios to manage ghc session, as hie-bios uses stack repl underneath for stack projects.
(original issue haskell/haskell-language-server#481)

Steps to reproduce

  1. Create a simple stack project with a main package with an exe and a subpackage with a lib
  2. Create in the subpackage lib a module with
import System.Directory
import Language.Haskell.TH
import Language.Haskell.TH.Syntax

cwd :: FilePath
cwd = $$(runIO getCurrentDirectory >>= \d-> fmap TExp (lift (d :: FilePath)))

and in the main package an executable with

main = print cwd
  1. Run command stack run and observe cwd is /path/to/main/package/subpackage
  2. Run command stack repl subpackage or stack repl and observe cwd evaluation gives us /path/to/main/package

Expected

Both paths should be equal.

Actual

stack build uses the subpackage path and stack repl the main package one

Stack version

$ stack --version
Version 2.5.1  x86_64 hpack-0.33.0

Method of installation

  • Official binary, downloaded from stackage.org or fpcomplete's package repository
@qrilka
Copy link
Contributor

qrilka commented Nov 15, 2020

@jneira I see that the situations stack repl subpackage and stack repl are a bit different. While checkout out what does cabal-install do in that situation I see the following:

$ cabal v2-repl package subpackage
cabal: Cannot open a repl for multiple components at once. The targets
'package' and 'subpackage' refer to different components..

The reason for this limitation is that current versions of ghci do not support
loading multiple components as source. Load just one component and when you
make changes to a dependent component then quit and reload.

I didn't investigate it further (yet) but probably Stack needs to take this problem into account.

As for the stack repl subpackage - it looks like cabal-install just does chdir when building (or running repl for) a package. This detail is easy to fix when it will be decided what to do about multi-package repl

@qrilka
Copy link
Contributor

qrilka commented Nov 18, 2020

@jneira it looks like in Cabal this error was added as a part of haskell/cabal#4179 but it doesn't list any links to GHC tickets describing concrete problems. As I understand it working directory could be one of such problems as we can't have different working directories for different packages in GHCi. And still loading multiple packages makes sense in some situations but I don't have any examples myself. Maybe @mgsloan could share some ideas about that.
At the moment the plan is to

  • add a warning about the problem when loading multiple packages
  • set cwd properly when loading repl for a subpackage
    Will this be an appropriate solution for HLS?

@jneira
Copy link
Contributor Author

jneira commented Nov 19, 2020

Many thanks for take care of that and share your investigation.

set cwd properly when loading repl for a subpackage
Will this be an appropriate solution for HLS?

I think so.

@qrilka
Copy link
Contributor

qrilka commented Dec 2, 2020

@jneira it would be great if you could check out #5448 which should fix this

@phadej
Copy link
Collaborator

phadej commented Dec 2, 2020

https://hackage.haskell.org/package/file-embed-0.0.13.0/docs/Data-FileEmbed.html#v:makeRelativeToProject

@qrilka
Copy link
Contributor

qrilka commented Dec 3, 2020

While #5448 will improve the situation here a bit the proper resolution is blocked by upstream as in #3310

@qrilka qrilka closed this as completed Dec 3, 2020
enobayram added a commit to kadena-io/chainweb-data that referenced this issue Aug 8, 2023
This PR adds a `hie.yaml` to the project and also works around the following HLS bug:

haskell/haskell-language-server#481

That issue is actually related to stack, but seems like the cabal integration is suffering from the same in our case. There are quite a few relative-path related issues open in HLS anyway.

This commit uses the `makeRelativeToProject` function from file-embed ([As suggested by phadej under another issue](commercialhaskell/stack#5421 (comment))) in order to resolve the relative paths in a way that's independent of the build system, working around this long-standing HLS bug.

* Add a hie.yaml to the project

* Work around HLS bug while embedding files

This commit works around the following HLS bug:

haskell/haskell-language-server#481

That issue is actually related to stack, but seems like the cabal
integration is suffering from the same in our case. There are quite a
few relative-path related issue open HLS anyway.

This commit uses the `makeRelativeToProject` function from file-embed
in order to resolve the relative paths in a way that's independent of
the build system, working around this long-standing HLS bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants