-
Notifications
You must be signed in to change notification settings - Fork 207
Hlint data-files can not be easily distributed #1143
Comments
hie
crash
hie
crash
Moreover: |
Is this a duplicate of #400? |
@nponeccop It does tackle a similar issue. I am currently in the process of evaluating runtime-dependencies of |
I propose the following, slightly weird, solution: Pro:
Con:
|
I would like to tackle this at install-time. My plan:
My suggestion is that @mpickering @fendor is this fine? |
Mmm i think the solution could be easier for hie and other hlint clients if hlint could look for the data files in a standard location, like |
I am pretty sure that if we made an appropriate PR on upstream |
I dont think that data-files can be installed into |
I think compile-time installation into the hie data area probably makes the most sense, as you suggest @fendor . |
My idea was honour the actual order but, after falling back first to actual It would be similar to the first option commented by @fendor but i feel Independently of the location, i see doing the copy of the file at build time as a complement with runtime, but if we want to use precompiled binaries (and i am firmly conviced that we should offer them) we'll need the second one for sure, right? Otoh, how could be done the copy of the file at build time? with a custom |
Does I dont think we are allowed to claim My idea would have been that we are listening to a special Obtaining the files at run-time would be doable, too. Yeah, a good error message must be added. |
yeah except looking in
I was thinking in add the support to hlint itself (cause i think it would be good for hlint users too)
Well to be fair this way (using
I think its main advantage is that it would cover all executable use cases (build from source, installing using cabal, stack or a os package manager, using directly the precompiled binary, etc)
It always would be needed, whatever we choose to do before that (including download the file at runtime: it could fail) |
I decided to implement it at run-time but also do the right thing at compile-time: Last question for me: should we offer to install the data-files to |
Back to the drawing board, after the feedback in #1540 As I understood it now, we can aim to perform the following:
Open questions:
|
mmm i think the last @alanz proposal was to do something similar to hlint itself (correct me if i am wrong):
NOTE: |
@jneira I agree with your solution, with the one proviso that the current usage continues to work. In other words, looking for the data files in this installed directory should be a fallback if they are not found where they are expected. If necessary we should make a PR on hlint to assist in this. |
This seems like a flaw in hlint. Packaging aside, If I do
|
It does not produce it at compile-time, it just compiles the location of I think, it also does something like that, too. You may want to take a look at ndmitchell/hlint#620, were we discussed this issue with the author. I am sure you can add something to it, if you want to. |
@fendor thanks for pointing that conversion out. |
Good news: we have to do nothing to get the required behaviour cause we already are hitting the code path that search the data files inside the executable path (in our case hie)
So only left package |
Closed by #1545 |
Reopen to track the file embed alternative. There is a pr opened by @Avi-D-coder in hlint: ndmitchell/hlint#824 |
hlint already has the data embedded: see #1587
|
I've tested it works locally, renaming hlint data files in the |
hlint
demands that its data-file locations are known at compile time. If you remove these files, for examplehlint.yaml
, hlint will fail with a message and letshie
crashIn this case, hlint has stored its data-files in
~/.cabal/store
.Unfortunately, if you copy the executable
hie
instead of installing from source,hie
itself chokes on that error, since the data-files are not copied, thus, not available. We should, at the very least, catch that error and avoid crash.Following options to resolve this issue:
hlint
into an official run-time dependency and demand a working installation.This is a blocker for #1068
The text was updated successfully, but these errors were encountered: