Pass Backend

[MagicRB]

Signed-off-by: Magic_RB magic_rb@redalder.org

Description

Add a pass backend calling the pass CLI program directly. As discussed in #55

Related issue(s)

Directly discusses #55.

:white_check_mark: Checklist for your Pull Request

Related changes (conditional)

• Tests

  • [ ] If I added new functionality, I added tests covering it.
  • [ ] If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • [ ] I checked whether I should update the docs and did so if necessary:
  • README
  • Haddock

• Public contracts

  • [ ] Any modifications of public contracts comply with the Evolution of Public Contracts policy.
  • [ ] I added an entry to the changelog if my changes are visible to the users and
  • [ ] provided a migration guide for breaking changes if possible

Stylistic guide (mandatory)

• [ ] My commits comply with the policy used in Serokell.
• [ ] My code complies with the style guide.

[MagicRB]

Ok, think that's. So this is a weird one, or rather weird 3. It's actually 3 PRs in one. I'll split them up before merge, but we can review them now together, since they all developed together, triplets so to speak. Anyway. PR list:

1. the actual backend, Backend/Pass.hs and Entry/Pass.hs
2. the supporting debug backend, very useful thing, Backend/Debug.hs
3. and finally an experiment. I needed a nice FS api and i wanted to try something more type bound, it's not as special as i wanted but it works and we can use it instead of IO, Effect/Fs.hs

Ok, so that's all. The last part I'm not happy with is Entry/Pass.hs, it's a parsing spaghetti hell as is common with marshalling code, but that in particular is hellish. I'm not really certain what to do with it, the format itself is a little thrown together since we're trying to fit into pass' standards. But, actually, it's similar to Vault, so maybe we could unify those formats. The main issue with the code right now, is the "modern art" of chaining functions and making little "pipelines". That would be solved by breaking the pipeline up into parts and giving those parts meaningful names. That's all.

[MagicRB]

Oh and I have no idea why it doesn't build. None at all, it builds on my machine:tm:

[MagicRB]

I've gone through most, thanks for the input. I've noticed that mostly you see more combinators that could be used to make the code simpler. I guess that comes with experience.

[dcastro]

Oh and I have no idea why it doesn't build. None at all, it builds on my machine

@MagicRB It's because you edited the coffer.cabal file directly.

We've since added support for hpack + stack, so now we should edit the package.yaml file instead. And then use ./scripts/generate-cabal-files.sh to update coffer.cabal, cabal.project, cabal.project.freeze, etc.

We have a CI step to validate that the stack and cabal files are in sync (see here), but the check seems to be faulty... the step succeeded in this PR's pipeline and it shouldn't :thinking: I'll look into this.

[dcastro]

We have a CI step to validate that the stack and cabal files are in sync (see here), but the check seems to be faulty... the step succeeded in this PR's pipeline and it shouldn't :thinking: I'll look into this.

Ok, found the issue, fixed it here: https://github.com/serokell/coffer/pull/77

[MagicRB]

https://github.com/serokell/coffer/pull/62#discussion_r857354074 idk why but i cant seem to reply to this, so doing it here. stringToPath is fine, we're not doing pathToString anywhere, which would be an issue.