search

atom-haskell-archive / haskell-ghc-mod

haskell-ghc-mod atom package
https://atom.io/packages/haskell-ghc-mod
MIT License
69 stars 20 forks source link

how to / some way to set different per-project paths to ghc-mod #54

Closed wolftune closed 8 years ago

wolftune commented 8 years ago

Since Stack supports having projects on the same system use multiple versions of GHC, it would be ideal for haskell-ghc-mod to recognize somehow which ghc-mod to use for a given project.

Perhaps a dot file in the project directory could be used to pass info to haskell-ghc-mod? I'm not sure what other approach could make sense.

The process as I imagine it would be this, in the project directory: stack build ghc-mod then stack exec which ghc-mod will output the full path to the ghc-mod built for that project. Then, that path can be somehow used by haskell-ghc-mod when using the particular project and could vary when working on a different project, depending on if they use a different GHC etc.

Note ghc-mod must be 5.4 or later for Stack, and I think that will be in LTS-3.6, so for any older projects using older snapshots, ghc-mod-5.4.0.0 (or some later version) will have to be added to stack.yaml*

lierdakil commented 8 years ago

On per-project basis, it's possible to achieve this right now, since local sandbox is prepended to search path. Long story short, if you have a .cabal-sanbox in your project directory, you can install a relevant version of ghc-mod in there, and .cabal-sandbox/bin will be prepended to your PATH automatically. Not sure if it makes much sense with stack though.

wolftune commented 8 years ago

Are you saying that this is something specifically that haskell-ghc-mod does? It knows to add .cabal-sandbox/bin to the path it uses regardless of system path settings?

So if a similar generalizable option for .stack-work was available it would work comparably?

FWIW, the executable could be copied to a .cabal-sandbox/bin directory as a workaround even if there's not any actual use of cabal sandboxes. The only issue would be needing to remember to update it since Stack wouldn't do that automatically.

lierdakil commented 8 years ago

Yes, that's pretty much what I said.

I'm not terribly familiar with stack, so I'm not sure on that account.

Yes, copying executables directly is certainly possible, although there might be some caveats regarding library search path with that. Creating symlinks is also a possibility on systems that support those.

That all said, there have been an idea brewing of allowing to use multiple ghc versions with any project, via a straightforward selection dialog, given minimal path setup. That would be tricky to get right, but isn't outside the realm of possibility.

thunky-monk commented 8 years ago

Hey, @wolftune did you figure out a good solution for this?

wolftune commented 8 years ago

@hamsterdam nope, everything I do is with the same GHC version so it doesn't matter to me right now, it's just an abstract issue unless someone else has this problem in practice.

thunky-monk commented 8 years ago

@wolftune thanks for the prompt response.

Have you gotten atom-haskell to work with stack at all?

wolftune commented 8 years ago

Yeah, I totally have ide-haskell in Atom working with Stack for the core functions like completion and types and everything

thunky-monk commented 8 years ago

@wolftune Would you mind sharing how you have it configured?

It works for me in the global project if I add:

but otherwise, when in a non-global project I get:

ghc-mod: cabal: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

wolftune commented 8 years ago

@hamsterdam if you have ~/.local/bin in your .profile PATH (or in .bashrc and start atom from bash), you don't need to specify that path. Also, you don't need the additional path directories set.

I think that error you have is because you have a dist/ directory in your project that might have been made by running something that built with cabal. You have to remove that

thunky-monk commented 8 years ago

Nope, not the issue. It's a clean stack project. Thanks for the tips, though.

welf commented 8 years ago

@hamsterdam Try to add all folders from PATH in your .bash_profile file to the Additional Path Directories field in haskell-ghc-mod settings. I've had the same issue https://github.com/atom-haskell/haskell-ghc-mod/issues/65 and it solved the problem.

thunky-monk commented 8 years ago

Thanks @welf. I tried that and got the same error that someone else did in #65.

lierdakil commented 8 years ago

So, well, as far as I can tell from skimming through referencing issues, it seems this should be basically renamed to "get PATH from stack". v1.6.0 does that, so various tricks with 'Additional Path Directories', stack exec atom etc should not be needed provided everything is set up correctly. See also https://github.com/atom-haskell/haskell-ghc-mod/wiki/Using-with-stack

Feel free to create new issues if something doesn't work or you have suggestions.

Note that v1.6.0 might break existing setups using .cabal-sandbox/bin hack. Sorry about that.

shanemikel commented 8 years ago

@lierdakil maybe I'm missing something, but with ghc-mod installed my project's cabal sandbox, as long as the plugin is set to look in cabal sandboxes, I shouldn't need to do anything special for my sandboxed libs to resolve, right? (The plugin will find the path based on atom's 'project folder', or should I need to start atom from within the project directory?) Is this what you mentioned about breaking the .cabal-sandbox/bin hack?

EDIT ... Hmm, I have no idea what I did, but it seems to be working now, maybe it was a rogue .cabal file I had in the project folder

lierdakil commented 8 years ago

@shanemikel, glad to hear you resolved it. My comment didn't have anything to do with resolving libraries, those are resolved by ghc-mod (usually correctly). This issue only relates to PATH environment variable (which controls where to look for executables).