Fails to install Haskell tools because it's using the wrong compiler #375
Comments
|
It's not what you think it is... That message is from that the plugin is using Stack to install the Haskell tools like hlint in an IntelliJ sandbox. Has nothing to do with your project. That LTS version is fixed to prevent API compatibility issues with Haskell tools. Your issue is: |
Unfortunately, yes it is. Believe me, I've researched this issue when it hit me way before I started my attempts to use your plugin. And the solution I had to pick (because I cannot allow
Yes, and the problem is with the way your plugin is doing it.
Please give the user the possibility to "unfix" it. For example, my LTS is 13.2, and I'm forcing my compiler (and things that I need to work - work fine with it):
Yes, that's the root cause - the question is how to work around it. Your plugin prevents the workaround - unnecessarily, I think. I am asking again - since your plugin, as you said in your README, To demonstrate that everything (else) is working on my setup: |
|
Also, please consider allowing user to pass |
That is in conflict with my solution, see the discussion under this commit for more context: The
The README is still for the latest beta I have published to the stable channel of the Jetbrains plugin repo. And here I can write a whole story............
Cabal |
Ok, will do that. |
Yeah, but that doesn't invalidate my point - that my setup was sound and solid. Here's the "pure" As you can see, works perfectly fine.
Thank you for providing the context - very informative. I understand your position better now. I still would like to ask for an option to use system-installed components, if at all possible. Say, make your current approach a default, but offer the possibility to specify the tools explicitly?
It did not seem to work before. I will keep experimenting, but I don't have much hope here. :-(
Yes please! This workaround worked for me with GHC itself, and with |
|
I would like to know what I can change to the stack command which installs the Haskell tools to get it working for you (and in general). The stack install command is ran from the home directory. Stack is used for:
Do they all need that extra ghc-options? Or only for installing Haskell tools and what is that ghc-option? As a workaround you can put the tool binaries in: |
First, please know that I really appreciate your willingness to seek solution to the problem I'm experiencing. Based on my observation, this problem is shared by everybody who uses Macports and has to put Macports libraries first in the search path (for whatever reason).
The problem is that
But if I do, won't the plugin try to re-build them? Another aspect of this problem is - what LTS (and therefore what tools, and particularly, what GHC) would projects created with this plugin use? Any GHC (from any LTS or otherwise) except for the one that's been rebuilt under Macports (like what I did) would require this option. But maybe it's addressed by your first bullet point. |
|
I have read your comments a couple of times but it's all getting too confusing for me... I will not ask why not use
No, if the binary is there, no rebuild for that binary. Binaries are
package.yaml is leading. Stack will generate cabal file from package.yaml. Maybe this is the cause of your issue when you used your test project with IntelliJ. Btw, to import project in IntelliJ you have to select
In the following
I do not understand why you want to delete files. Stack creates in home dir only
I do not see that rebuild in the log above that sentence. FYI: intero gets build per project because it has to be build with same GHC version as Haskell project. Once it is build, it does not get rebuild each time project is opened. But anyways, it looks like most of the issues can be solved by setting ghc options in global stack config, project local stack config or cabal file. The plugin will not be changed to change any of the user it's files. Also for now the plugin only support Haskell Stack projects. Including the way it's behaving. So Stack projects use GHCs which are installed by Stack otherwise it's getting too complicated to make the plugin solid in general. For example, a user can have multiple Haskell project with each a different Stackage resolver. It is already complicated to get it working on WIndows, Linux, Mac and with with Nix. Besides may other problems... I still want to help you but you have to be specific in what I can do for you. When you need ghc-options to be passed to installation of the Haskell tools, no problem. Same for building the project and intero. But solution seems to be in setting those ghc-options in stack and/or cabal config files. |
It is even more confusing to me. ;-) So now I need to figure how to untangle this mess. What I'm leaning to now is removing my modified compiler altogether. If I have to use the "unmodified" (the original) one for anything at all, then presence of two differently-configured GHC compilers is a big problem. Then, I'd have to nuke my current cabal and stack databases, and update them a-new, with the GHC from Haskell Platform. Of course, I'll also need to make sure the configuration for all of these has the appropriate I'm still in the process of figuring out the least damaging way of accomplishing the above.
Because there are negative consequences of two GHC compilers being used - and I need to eradicate them.
There are reasons, besides being reluctant to change everything this machine had since 2011. ;-)
Not really. And the amount of packages that Macports serves is about 3 times greater than what Brew has, AFAIK. But that's not the main factor in my case.
Ah... I did not realize that. But if several projects are built with the same GHC - would they share the same
That's what I'm currently experimenting with - trying to find whether there are some config parameters for
What about files like
Believe me, I appreciate this!
Excellent, thank you! I'm certain that if those options are necessary - they'll have to be the same for user projects, Haskell tools, and Would you consider adding a plugin config parameter that would contain
I do not know yet. I think adding the ability for the user to configure the plugin to pass
I'm happy for you - to be able to reproduce this issue regularly is not a pleasure! ;-) |
UpdateI removed my modified compiler, and added the appropriate My projects seem to build fine, including installing First, I'd much rather have an option to tell this plugin "please, use this Update 2It tries (and fails!) to build a new Update 3I take some of the above back. The original (unmodified) GHC fails to build Here's the result: |
|
@rikvdkleij would you consider adding support for UpdateIt would help if in the config for IntelliJ-Haskell I could specify flags to pass to Also, it looks like it would help if I could force |
|
@rikvdkleij would you be able to notify me (e.g., by posting here) when you add the ability to pass flags/parameters to all |
|
So one set of flags for all |
|
I am not certain, but it seems that if the plugin would allow the user to enter a string, which could be comprised of multiple arguments/parameters/flags, and pass that string to every And yes, I'd probably start with just one "string" (one "set of flags"). It's possible that we'd need more - e.g., a set of flags for building projects, and another set of flags for building Haskell tolls, etc. - but at this time I think/hope that it wouldn't be necessary. |
|
I'm busy with implementing that feature but problem is that not every stack command accepts the same options. For example, |
|
Do you also need those extra option when building the project itself? |
Thank you!
I vote for your proposed solution, at least for Are you aware of other Also, I thought that your plugin would just pass just a user-supplied string, which wouldn't have to be a set of parameters for
I'm sure I do need extra options there. But I'm not 100% certain that I need those ones (it's just that so far the same options I needed for the Also, I haven't figured out what to do with So, maybe you could figure what to do with possible inability to build a "local" |
Yes, that's what I'm doing. The point is that those options have to valid for every stack command that is executed. |
|
About `ghc-paths', maybe the custom Setup.hs is the problem: But I do not know how to solve it... |
|
I want to replace intero by another Haskell backend but that takes some time. |
Oh yes, that's clear. Perhaps you want to put it in the README - that if a user decides to utilize that capability, he better consider and understand the consequences - such as that whatever he'd put there must be valid for all the Possibly, having more than one "extra options" parameter - like, one for (user?) projects, one for building Haskell tools, etc. would mitigate this to an extent, as one would be able to configure two different sets of
I'm afraid that
Understandable. Also, if you have an idea what that backend is likely to be - perhaps it would pay for us to try it now, maybe directly from |
https://github.com/mvoidex/hsdev is a good alternative. Switching to this one is a large change. |
I see. Tried to install it via You can observe that the BTW, when would your plugin with da0fe5b commit update would be available for IDEA? I checked today, but the version it offers is from Jan 09, 2019. Update |
There is a cabal flag to not include hlint in the build.
Sorry, I can not help you with that.
Did not release a new beta yet because busy with other changes which I want to include in the new beta. |
|
@mouse07410 I will so release asap. Have some test issues. |
Thank you!
Understandable. Your efforts are appreciated! |
Excellent!! Do you have any idea how quickly IntelliJ is likely to make this update available via their Alpha update channel? Thanks! |
|
Can take some days. You can also install beta from disk. |
|
Installed the update. First, now even the projects that used to build, fail at linking: The problem appeared to be Other projects also build OK, when I import them. However, the plugin fails to create new projects: It seems that different invocations of
|
I do not understand this. The second one does not seem to a valid ghc option. Maybe I have to put quotes around the value or make the setting only for --ghc-options instead of a general string which is passed to stack and then to ghc.
Sorry. but that is unmaintainable. We have to find right solution for this issue... What works and what works not without --ghc-options? I will also exclude |
Yet it is correctly interpreted as an input for the linker, and passed to it correctly. While in the other case, the correct parameters are appended to the pre-defined ones, and so have no useful effect - the "wrong" library by this time has already been found, and the error has been thrown.
Please don't. This is something that I can experiment with, and a user would have no problem adding quotes - while it would be impossible to remove them if you put them in your plugin and they turn out interfering (as I suspect they would).
That's what we're doing! ;-)
It looks like
Yes please - that seems a good start.
Please don't put quotes around it.
I can experiment with this, but the problem seems to be not that this parameter didn't get passed (and it's passed single-quoted!), but that it's passed after all the other parameters, thus coming in too late. Also, another related issue: it looks that when a Haskell project is opened, either Also, it would be nice if there'd be an option to "Clean" the project without re-building. Thanks! |
That's on purpose to be sure that all dependencies are build otherwise REPLs will not start. |
|
Then perhaps do not (or make an option to not) start REPL automatically, because building dependencies with wrong or incomplete parameters is not good, regardless. |
|
In beta42 the extra options are not passed to |
|
Thanks - will try it as soon as it's available on IntelliJ Alpha update channel. |
|
With I suspect it's the problem with Could you please stop automatic build of the project? Or at least give the user config option to disable automatic build? Also, since P.S. My sample projects seem to build fine, if you don't count wasting approximately 1GB of disk space per two simple (a-la "Hello World") projects, thanks to |
So I can remove the settings field to pass options to stack commands?
That does not solve your problem. Stack is also used for building intero, installing tools and running the REPLs with Intero. Intero only works for stack projects.
Yes, that would be solution together with replacing Intero by another Haskell backend. But this takes some development effort. Btw, I already did some preparations to decouple features from stack but still it's a lot of work.
The nice thing of using stack is that one does NOT need a globally installed GHC. So every project can have a different GHC version. With Cabal one has to use for example Nix to prevent globally installed GHC. |
|
Alternative way for installing GHC, https://github.com/haskell/ghcup |
Please don't. This is a very useful feature (regardless of the backend type, BTW), even if there are a few packages (like
I hear you, but don't fully understand: on my setup there's no way to build either
This is a matter of preference. To me GHC "sprawl" is not nice. I'm coming from a "disciplined software design" background, where interfaces are thought over carefully, and then don't change like daily temperatures. I do a lot of programming, run a lot of projects (some in Haskell, the majority in other languages - as you can guess, I'm paying for IntelliJ license not via Haskell projects ;), and have no disk space to waste on useless replications (especially with the magnitude of extra space that
Yes, this is one reason among many why I prefer Cabal oner stack. And instead of preventing use of the globally installed GHC, I'm trying to enforce it where I can.
And I'm exactly opposite - I do want and need a globally installed GHC.
Yes, I know. I'm discussing with developers the options/capabilities. In general, it isn't ready yet for MacOS the way I'm using it - and it won't help with my problems anyway, because the "main" GHC works fine (and so does Cabal) on my machine. It's when
I realize that enabling Cabal as a build env alternative is a significant effort, and could take considerable time. I still welcome that development. Thank you! |
I still wonder if it makes sense to have setting to add extra options to stack commands because it sometimes works and sometimes not. Very confusing for future users. |
There is only GHC version per computer (when needed) 😄
A lot of features depend on running the stack repl with intero as plugin. So stack repl to have a repl in the context of the project and intero for features like definition location and type info based on location. Can do the same for the Haskell tools binaries which has the risk that supports breaks because the API is not compatible with what plugin is expecting. |
There should be only one GHC version - but in my experience, Not to mention all the other
YES! This risk is perfectly acceptable to me, and would be stated by the developer in the README to warn those who shouldn't be doing that.
YES! Yes, please! Note, that IntelliJ already does this for most everything it provides - it detects what it can, and allows you to override those locations. So, for example, I set it to use my own Maven. Just expose the defaults, allow user to override them, and state that risk in the README. E.g., telling the user that he shouldn't modify the defaults unless he both understands well what the consequences could be, and has a good reason to diverge from those defaults. Maybe in that case, automatic build upon project import won't be necessary? And/or maybe it could be controlled by a config option, like "Do not build the project automatically"? |
|
AFAIK this one can be closed. |
|
Yeah, it's fine. One problem - the current plugin does not support operations like "stack clean" (which is necessary to deal with cases when, e.g., there are artifacts stuck in the project that prevent it from running correctly). There's no way to request such an operation, and no way to prevent plugin from forcing the executable (that it consists the right one). |
MacOS Mojave 10.14.2, IntelliJ IDEA 2018.3.3, GHC-8.6.3 (rebuilt - see below)
My systems have Macports installed. That makes it impossible to link static Haskell executables, because Macports introduced its own copy of
libiconv.dylibthat mangles function names - which in turn makes it impossible to link anything withlibHSbase.a(see https://trac.macports.org/ticket/57821).Here's what the failure looks like:
And here's the log file it refers to:
hoogle-log.txt
There are two solutions:
/opt/local/binthat precedes/usr/local/binon the PATH), so it is linked against Macports, so it'slibHSbase.ais happy with Macports-providedlibiconv.dylib./usr/lib/libiconv.dylibto each and every invocation of GHC.My
~/.cabal/config.platformand~/.stack/config.yamlrequire system-ghc, but apparently this plugin doesn't honor it, and when it downloads a "standard" resolver with its own GHC - that GHC fails the link phase onlibiconv.dylib.What I'd like to see in this plugin:
The text was updated successfully, but these errors were encountered: