search

phoityne / haskell-debug-adapter

Debug Adapter for Haskell debugging system.
https://hackage.haskell.org/package/haskell-debug-adapter
BSD 3-Clause "New" or "Revised" License
54 stars 8 forks source link

feat: add nix build infrastructure + github workflow for tests #29

Closed mrcjkb closed 1 year ago

mrcjkb commented 1 year ago

Hi.

I am looking into adding support for haskell-debug-adapter to my haskell-tools.nvim neovim plugin. This means I may become interested in contributing to this project in the future. :smile:

As I use NixOS for development, I have added some infrastructure for using nix to build this project and run tests - which I am requesting to merge with this PR.

I have also added a GitHub action that runs the test suite on PR and push to master.

The nix flake uses pre-commit-hooks.nix to

This could potentially be extended to also run hlint and a Haskell formatter. I have omitted these, as they would result in modifications to the Haskell source files. A potential downside to adding linters and formatters is that the CI could fail if someone uses a different version of hlint or the formatter than the version used in the nix build. For anyone who has nix installed, this is not a problem, as long as they use nix develop to enter a nix shell with the correct versions of the packages installed.

The same applies to the haskell-debug-adapter.cabal, which is generated by hpack. The file has been changed in this PR, because the nix infrastructure uses a newer version of hpack.

hpack has lowered the lower bounds of the dependencies in haskell-debug-adapter.cabal. This indicates that the package.yaml and stack resolver is not the source of truth for this build (?). If need be, I can revert that change and remove the hpack pre-commit-hook. Although this discrepancy looks to me like it could lead to inconsistent results between stack and cabal builds.

mrcjkb commented 1 year ago

Marking this as a draft. It might be better to use the locally checked out repositories as inputs, instead of the dependencies on hackage.

phoityne commented 1 year ago

Thank you for your contribution. I'm going to check building with your cabal file locally.

mrcjkb commented 1 year ago

@phoityne I have added the nix infrastructure to https://github.com/phoityne/haskell-dap/pull/14 and https://github.com/phoityne/ghci-dap/pull/11.

They are used as inputs for this flake, allowing for hermetic builds during development. If either of the dependencies is changed, the changes can be applied to this project with nix flake update.

Note: IMO, these projects would be easier to maintain if they were merged into a monorepo. Is there a reason you have chosen to put them in separate repositories?

phoityne commented 1 year ago

Hi. I'm not a NixOS user. Is this PR what haskell-tools.nvim needs ? PR to build haskell-tools.nvim on haskell-tools.nvim repository ?

Or an improvement suggestion for this project ? (such as auto lint, build, test,, by github actions.)

mrcjkb commented 1 year ago

It's not needed for haskell-tools.nvim.

(nix can be used on any Linux distro and on MacOS).

The GitHub actions workflow is an improvement suggestion.

phoityne commented 1 year ago

Thank you for the suggestion. Is this still draft state ? Because no side effect to users, released packages, haskell-tools.nvim, I think it's ok to be merged.

mrcjkb commented 1 year ago

Thank you for the suggestion. Is this still draft state ? Because no side effect to users, released packages, haskell-tools.nvim, I think it's ok to be merged.

I just have to update the flake inputs for ghci-dap and haskell-dap to point to your repos (they currently point to my forks) and update the lock file. Then this should be ready.

I'll do that later today.

mrcjkb commented 1 year ago

Done. This is ready to be merged :)

phoityne commented 1 year ago

Thanks for your contribution. merged.

In the future, I hope to be able to use the same mechanism to check builds and create binaries.

Especially ghci-dap, I think you can install it with ghcup if we prepare binaries for each distro and ghc version.

mrcjkb commented 1 year ago

Sounds reasonable.

If ghci-dap is a requirement for haskell-debug-adapter, it might make sense to package them together.

The nice thing about using nix for tests/checks is that they can be reproduced locally by anyone who has nix installed. That can often be difficult with GitHub actions. But for this project, it definitely makes sense to test with different ghc versions, too.