You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 12, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 12, 2020. It is now read-only.
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
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.
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.
@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.
Out of curiosity, is there a list of several commonly used tools for haskell that:
work on windows/macos/linux
would be commonly used in CI as validation steps
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?
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.
Activity
LeifW commentedon Jan 7, 2020
Is there a way to add hlint yourself, even if it's not added by this action?
patrickt commentedon Jan 7, 2020
@LeifW You can always
cabal installand cache it (as here), or you can runwgetto download a Linux binary from the releases page.lapplislazuli commentedon Apr 14, 2020
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?
What do you think @patrickt & @LeifW ?
LeifW commentedon Apr 14, 2020
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 hlintto add it.https://github.com/LeifW/udev/blob/master/.github/workflows/haskell.yml#L17
patrickt commentedon Apr 14, 2020
I'm not sure what you mean by this; installing the
hlintbinary shouldn't impair or interfere with anyone's use of other packages, especially if it's installed via apt-get.lapplislazuli commentedon Apr 16, 2020
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
packageswas 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 😃
patrickt commentedon Apr 16, 2020
@Twonki Ah, I get you. As far as things like
quickcheckand 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 anhlintexecutable somewhere like/usr/local/bincausing trouble even for people who manually installhlint. And installing a binaryhlintfromapt-getallows us to sidestep the issue of having to install any Hackage libraries to compilehlintitself.hazelweakly commentedon May 5, 2020
Out of curiosity, is there a list of several commonly used tools for haskell that:
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
hlintas 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 theactionsorganization include options for setting up commonly used language tools like formatters and style checkers (that I noticed). However, theactions-rsorganization does have actions that do this, including theactions-rs/toolchainaction that accomplishes a very similar thing. So it's certainly not unprecedented.I'm leaning towards setup for
hlintCLI tools belonging in a third party action to not diverge the haskell action too much from the rest of theactions/setup-Xrepos. It might make more sense for such an action to belong to the haskell-CI organization. Thoughts?chshersh commentedon Jul 27, 2020
@jared-w Another tool that can be used as a validation step on CI is Haskell Static Analyser Stan.
Stan works on all 3 major operating systems and provides binary releases, so it can be simply downloaded, if users want it.
Specifying it as
packagesor eventoolsoption as @Twonki proposed seems ok to me. And I'm happy to collaborate and work on Stan to make the integration with thesetup-haskellaction 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 commentedon Nov 15, 2020
If you want to run HLint on such a repo, you can do:
That doesn't require an install, and automatically fetches an appropriate binary.