chore: vendor hasql - #5084
Conversation
Pipelining mode
As a workaround for Hackage including the dependencies of internal libs in the public list of package dependencies.
* master: Update actions
* clean-up-public-deps: Remove rerebase from the internal library deps
Report errors when LISTEN or UNLISTEN fail
Remove stack from repo since I am currently working only with cabal
This prepares the merge into the postgrest main repo. To avoid merge conflicts and give a clear history wrt renames, all the files are moved to a vendor/ subdirectory first, before they are moved to their final location.
This prepares the merge into the postgrest main repo. To avoid merge conflicts and give a clear history wrt renames, all the files are moved to a vendor/ subdirectory first, before they are moved to their final location.
3b09a5b to
04d651b
Compare
04d651b to
74fd5d9
Compare
This prepares the merge into the postgrest main repo. To avoid merge conflicts and give a clear history wrt renames, all the files are moved to a vendor/ subdirectory first, before they are moved to their final location.
6591271 to
299d40c
Compare
|
The commit check can't pass due to the big number of historic commits merged here. Everything else should pass by now. I do wonder whether we should merge this - or wait a bit and cut a v16 release first. This certainly needs follow up (inclusion of tests, reduction of code, ...), so we might want to have a last release without vendoring first. |
Agree, let's do it for v16. |
After v16 maybe we could merge this into another branch and remove what we don't need before merging into |
This removes everything from the vendored hasql packages, except their license, source code, tests and .cabal file. We also remove metadata which is not needed anymore from .cabal file, but leave everything that needs to be ported to our own .cabal file later in place.
It's all MIT, so it will be enough to keep the additional copyright notices.
To run it, we need to remove the Arrows extension from postgrest.cabal. It doesn't seem to be depended upon by the hasql code (but was still introduced along with it), but breaks the style check. That's because stylish-haskell applies all extensions found in the .cabal file for all files, even when they are only part of *one* component. The Arrows extension makes `proc` a reserved keyword, which is used in CallPlan.hs.
I did not fix all of these by hand, but used the `--refactor` flag on hlint to do it for me. This is something that we might want to add in the future by default.
299d40c to
450759c
Compare
Not sure what we'd gain by doing that. I could either iterate on the already existing branch - or merge straight into main. We're not going to squash the related commits anyway, so for the history on main, it doesn't really matter? I think we should just go straight into main and iterate in regular PRs. |
13 participants
Step 2 for #4823. This replaces the
hasql-*dependencies (which includeshasql-notifications, but I don't know of a way not to fork that as well, since it depends onhasqlitself) with a vendored copy keeping the original history.We're only using the source code, so far, but not the original tests. That will be a next, separate step to merge these tests with ours and integrate them into the nix tooling etc.
Right now, it builds. Let's see what CI says - I assume it should also pass all our tests.
TODO:
Depends on #5093 and #5094.