TODO

[MangoIV]

This is a meta issue tracking the issue this flake is trying to/ has to resolve and the status of the issue.

Tooling

• [ ] provide reliably cached tools for different used ghc versions (and disallow/ discourage use of any other ghc versions)

  • [ ] plutarch ghc (ghc921)
  • [ ] plutustx ghc (iohk ghc8107)

• [ ] CD hoogle for tooling and deps

• before: case study; which dependency set/ tooling and so on do people use and why; how do they compose their nix flakes, what would make integrating this easy

• [ ] provide outputs with current library version for all libraries used by mlabs

  • [ ] provide outputs
  • [ ] provide a fixed set of supported nixpkgs; this should be minimal
  • [ ] provide wrappers to simply use the outputs downstream
  • [ ] provide checks that build and cache the libraries
  • [ ] (provide generic tests in plutus-scaffold to check whether library changes break something)
  • [ ] make subflakes for different repos/ nix toolings
  • [ ] make maintainers of library aware of this flake; add them to the feedback loop
  • [ ] plutarch
  • [ ] staging
  • [ ] master
  • [ ] respective tooling
  • [ ] ply
  • [ ] plutus-simple-model
  • [ ] plutip
  • [ ] bpi
  • [ ] plutustx
  • [ ] ctl
  • [ ] develop
  • [ ] master
  • [ ] runtime environment
  • [ ] lucid
  • [ ] main
  • [ ] (vasil)
  • [ ] tooling for typescript?
  • [ ] for all haskell projects:
  • [ ] hls
  • [ ] fourmolu
  • [ ] hlint
  • [ ] cabal-fmt
  • [ ] (any other haskell tool that a downstream users needs)

Plutus scaffold

• [ ] make plutus-scaffold use this flake and completely rewrite it

CI

• [ ] easily adjustable checks for flake users that check
  • [ ] all executables
  • [ ] all libraries
  • [ ] build devShells
  • [ ] run tests
  • [ ] run formatting checks (styleguide flake?)
  • [ ] are ideally extensible
• [ ] bot that runs nix flake update and check afterwards to see where breaking changes occur, as in https://github.com/DeterminateSystems/update-flake-lock

Nix tools for creating projects easily

• [ ] provide easy to use wrappers to set up a cardano projects
• [ ] provide easy to use and well-documented wrappers with well-documented parameters

update cycle/ feedback loop

• [ ] on downstream projects: add a github action that
  • runs a nix flake update
  • runs CI
  • if CI breaks, report an issue to the dependency that broke including a build log

An issue that currently occurs is that library maintainers have a too lose feedback loop with their downstream library users. We want to tighten this feedback loop to make library authors be responsible with breaking changes and help fixing them if things go sideways downstream. This also implies the obligation for downstream users to more often report their problems so library authors can see what's wrong and help fixing. This will ultimately save a lot of time because work doesn't get duplicated and people who actually know the library can fix issues.

I don't know yet how to fix this problem but I imagine this repo to be the main point of raising issues. That will make this a hub for everyone in the company to go to if they want to see an issue resolved/ look for help with their issue.

This would also be the place where library authors have the obligation to go to get feedback on their library and announce breaking changes, ...

Other

[MangoIV]

I just came to the realization that for all the helper tooling (i.e. hlint, hls, fourmolu, ...) we can just use the normal upstream nixpkgs which is very reliably cached and also included tooling that is newer than the one in the haskell.nix nixpkgs

[srid]

For autoformatting / formatting checks, you may want to review https://github.com/numtide/treefmt-nix (see the issues for pending work to be done).

[brainrake]

@MangoIV can we do a review/update of this issue?

[MangoIV]

@brainrake we should probably, sorry for missing your comment.