Move away from `protolude` and create our own `Prelude`

[taimoorzaeem]

Problem

Considering #1804 (comment) and #1804 (comment), we should work on our own Prelude module/library.

Solution

Have a Prelude library/module with similar design points as protolude. We can add to it our own utility functions to it (e.g. composed hasql encoder/decoder functions as observed in #4297 (comment)).

[taimoorzaeem]

Similar to #4823, I think we should add this library under src/Preliminary or we can also add to project root under prelude/Preliminary, however the former seems more reasonable than the latter. This separates it from src/PostgREST to avoid exposing this internal library.

To avoid conflict with base's Prelude, I am thinking of naming it Preliminary 🥲. I would love name suggestions if any.

[wolfgangwalther]

https://stackoverflow.com/questions/35357198/how-to-correctly-define-your-company-prelude mentions a "New! Project-local Prelude, without mixins" approach that we could try. We already only build on GHC 9.10 and 9.12 by now, so this could work. In this case the name you'd be looking for would be... Prelude :)

[taimoorzaeem]

I am thinking of moving to our own prelude in the following steps:

• Vendor protolude. Including the copyright notice in each module. It would be easier to review.
• Remove all unneeded modules, CPP-directives from it.
• Rename the vendored protolude to prelude using mixins.
• Anything else that comes up.
• Later we'll modify our prelude according to our own needs.

WDYT?

[wolfgangwalther]

• Vendor protolude. Including the copyright notice in each module. It would be easier to review.

I'd do it similarly to how we merged the postgrest-docs repo into the core repo and how we'd do it with hasql: Merge protolude's history into this repo, move the relevant files into src/Protolude or so. Move them as-is, and keep their LICENSE document in that folder as well. Remove all other files.

[taimoorzaeem]

Hmm, what's need for merging protolude's (git) history? Why not just move the modules directly?

[wolfgangwalther]

Losing history will make you hit a wall, when you want to git blame changes to find the reason for how things are later. I'm sure things will come up while reducing the code to the minimum required for us in step 2. I, at least, frequently use git blame to track down changes' history.

[steve-chavez]

Merge protolude's history into this repo

Oof, seeing #4861 I don't think we should do it like that as it heavily pollutes our own history 😨

Or am I misreading the intention here and we'll not merge that PR? If not, can we do it in another way?

[wolfgangwalther]

it heavily pollutes our own history 😨

How so? You won't even notice these commits during normal operation, because they are many months / years old. The frequency of commits over there is rather low, so they will hide way in the past for us.

[steve-chavez]

Edit: resolving this comment, on second thought it's not critical just a nicety.

How so? You won't even notice these commits during normal operation, because they are many months / years old

It sounds really sloppy and will hurt my workflow badly 😿. So I use git on vim and navigate the log with usual vim shortcuts (gg for top of the history, G to the first commit, /<word> to search) as it can be seen here:

out-14.mp4

Now just imagine trying to search for bump in the git history and run into protolude matches (the commits on #4861 look pretty loosely redacted too)