Open falsandtru opened 5 years ago
What is the bug here? Are you actually reporting the final line ?
hie-8.2.2: user error (Failed to find requested hint files:
.../.local/bin/data/hlint.yaml
)
HIE shouldn't try to use such old version in the first place: HIE(hie-8.2.2) Version 0.6.0.0, Git revision 5245042a317944f394de20b29c55afd0bb0dbc76 (dirty) (2426 commits) x86_64 ghc-8.2.2
That is a good point. The wrapper should be a lot more precise about which version of hie it invokes.
Why shouldn't it try to use a version of hie that fits to the used GHC?
No old hie version is ever being downloaded, if this version is being used, then it was installed on the system. I dont see why the wrapper should perform a version check in this case. I should be able to use an old hie version if I want to, maybe it is more stable for my project, or I dont want to recompile every version.
EDIT: Also, the error in the last line is fixed in 0.8.0.0
, or at least does not cause hie to crash.
I think very old versions should be rejected (Accept only 8.x.x in this case). And should warn or notice the use of old version (with 8.x.x).
Why should it? they are still working, older versions support sometimes older ghc versions, e.g. pre 8.x.x is supported only by very old versions. However, if they work for you, why should you be spammed for it?
I thought old versions such as 6.x.x of HIE are not needed. If old versions are sometimes needed, they have to be accepted. However, warning/notification for the use of old version would still be helpful.
They are not really needed, but also it is not a strict requirement to always have the most up-to-date version. It is also somewhat hard to know when there is a more recent version, what should the wrapper do, call home and ask what the most recent version is? Or is the version hard-coded in each wrapper version? If we can define a solution here, it shouldn't be too hard to implement.
I think I would prefer it if the wrapper used absolute paths but I'm not a user.
It makes a lot of unnecessary debugging.