Provide `hlint` executable.

[patrickt]

This would be really nice to have by default.

[LeifW]

Is there a way to add hlint yourself, even if it's not added by this action?

[patrickt]

@LeifW You can always cabal install and cache it (as here), or you can run wget to download a Linux binary from the releases page.

[lapplislazuli]

I think having hlint is not what most people expect from a setup-haskell action.

Other people would be missing other libraries too then, such as quickcheck or hunit or something other essential.

However, I think whats maybe a good idea is to have a list of packages to be installed with the github action?

    - uses: actions/setup-haskell@v1
      with:
        ghc-version: '8.8.3'
        cabal-version: '3.2'
        packages: 
            - quickcheck
            - hlint

What do you think @patrickt & @LeifW ?

[LeifW]

I'm a bit confused - quickcheck and hunit are libraries, and as such if I used them in my project, I would add them as dependencies to my .cabal file. They're also not universally used. There's a few executables that are pretty standardly seen in CI setups - hlint being a pretty common one. happy might be another, though I haven't required it yet. For now I've just been running apt-get install hlint to add it. https://github.com/LeifW/udev/blob/master/.github/workflows/haskell.yml#L17

[patrickt]

Other people would be missing other libraries too then, such as quickcheck or hunit or something other essential.

I'm not sure what you mean by this; installing the hlint binary shouldn't impair or interfere with anyone's use of other packages, especially if it's installed via apt-get.

[lapplislazuli]

Oh man now I feel embarrassed.

I mean that both hlint, quickcheck, etc. are common things in haskell, but they are addons. And I'd not expect having addons if I sign up for a standard action. For example if I get Visual Studio, which can support e.g. python, I am asked to opt in for python. I think this is reasonable behavior.

Therefore I think it might be good to opt in for hlint, or other utilities, with the standard action and writing it as packages was just one proposal of how the opt-in could look like.

Also I think that maybe someone will face the issue that he is (currently) running the action as mentioned above with immediately installing hlint afterwards, the change of making hlint pre-installed and linked might cause unexpected issues.

I didn't mean to confuse or bother you :smiley:

[patrickt]

@Twonki Ah, I get you. As far as things like quickcheck and other Hackage libraries, it would be the wrong thing to install any versions globally, since we want to support multiple GHC versions and sandboxed Cabal builds. As such, individual projects’ .cabal files are where those should go, rather than in an Actions .yaml file.

In contrast, for PATH-accessible binaries like hlint, I think it’s reasonable to include in the image, since no one has to take advantage of it unless they want to in their Actions config, and I don’t anticipate the presence of an hlint executable somewhere like /usr/local/bin causing trouble even for people who manually install hlint. And installing a binary hlint from apt-get allows us to sidestep the issue of having to install any Hackage libraries to compile hlint itself.

[hazelweakly]

Out of curiosity, is there a list of several commonly used tools for haskell that:

1. work on windows/macos/linux
2. would be commonly used in CI as validation steps
3. can be installed as binary downloads (ideally through github releases somewhere)

The reasoning for 1 is that the rest of the action works on all three OSes, so ideally there aren't any settings that require one OS vs another. The reasoning for 2 is to avoid taking on a lot of technical complexity for tools that not many people would use. And the reasoning for 3 is to keep action setup time to a minimum.

Off the top of my head, I can think of hlint (fits all criteria), ormolu (no binary releases), brittany (no binary releases, doesn't seem to support latest versions of GHC), stylish-haskell (linux binaries only), and I'm sure there are others floating around.

Would it make sense to special case hlint as an option, or to provide somehow a list of programs that could be installed through the action, or neither? None of the other language setup actions in the actions organization include options for setting up commonly used language tools like formatters and style checkers (that I noticed). However, the actions-rs organization does have actions that do this, including the actions-rs/toolchain action that accomplishes a very similar thing. So it's certainly not unprecedented.

I'm leaning towards setup for hlint CLI tools belonging in a third party action to not diverge the haskell action too much from the rest of the actions/setup-X repos. It might make more sense for such an action to belong to the haskell-CI organization. Thoughts?

[chshersh]

@jared-w Another tool that can be used as a validation step on CI is Haskell Static Analyser Stan.

• https://github.com/kowainik/stan

Stan works on all 3 major operating systems and provides binary releases, so it can be simply downloaded, if users want it.

• https://github.com/kowainik/stan/releases/tag/v0.0.1.0

Specifying it as packages or even tools option as @Twonki proposed seems ok to me. And I'm happy to collaborate and work on Stan to make the integration with the setup-haskell action as simple as possible! 🙂 The only thing to keep in mind at the moment, is that due to usage of GHC API, Stan binary should be downloaded for the same GHC version as used in the workflow. But Stan itself provides such binaries for different GHC versions.

[ndmitchell]

If you want to run HLint on such a repo, you can do:

curl -sSL https://raw.github.com/ndmitchell/hlint/master/misc/run.sh | sh -s whatever-arguments-to-hlint-go-here

That doesn't require an install, and automatically fetches an appropriate binary.