Migrate dhall-{bash,json,text} into this repository

[Gabriella439]

The motivation for this change is:

• To catch build failures in downstream packages whenever we make a breaking
  change to the dhall API
• To reduce the amount of work I need in order to cut a release for all of
  these packages
• To better share Nix/CI-related logic between the projects

Note that I have not yet migrated dhall-nix in. I'm waiting for
dhall-lang/dhall-nix#17 to be fixed since
dhall-nix is incompatible with later versions of megaparsec due to
hnix.

[jneira]

Wow, the repo is going to be really big and devs will have to download all of them. Otoh the possible projects to join could grow (dhall-to-cabal f.e.?)
Have you considered use submodules, to get some of the advantages of both structures?

[Profpatsch]

Wow, the repo is going to be really big and devs will have to download all of them

Uh, it’s going to be in the low megabytes. nixpkgs has 1.2GB, and that’s about the biggest open source repository I know.

Big +1 on consolidating into one repo. Those tools belong together.

[Gabriella439]

@jneira: It's only 13 MB large, 9 MB of which is just the .git directory (so only 4 MB of actual code)

Other downstream Haskell projects don't have to merge into this one. I chose these ones because I maintain all of them and I often release all four projects in sync with one another. However, other downstream projects are welcome to merge into here if they want.

The benefit of merging in downstream repositories is:

• Nobody can merge a breaking change to the dhall package without fixing downstream packages in the same pull request, which lowers their maintenance burden
• They can reuse the CI logic from this repository, including the logic for building fully static tarballs

You can find a similar idiom in other groups of Haskell projects like servant, gloss, and codeworld

[ocharles]

I'd argue that all the ci benefits you talk about have nothing to do with using a mono repo. Hydra is perfectly capable of giving you the guarantees you need with multiple inputs. If it's easier to manage by all means go for it, but we should be clear about what is truly attained with this.

[jneira]

Sorry, "big" was not the correct word. I wanted to mean that you have to handle all the projects always and maybe you are interested in a subset of them in some context or for some task.
Anyway i understand the practical reasons to join them.

[Gabriella439]

@ocharles: What I meant was:

Suppose that I need to override the version of the repline dependency for dhall? Which repository does that logic live in, given that all of them need to pick up the override in order to build dhall (either directly, or as a dependency)?

[Gabriella439]

I will go ahead and merge this, then. The reason I'm not pausing for a long review period is because this will conflict with any in-progress branch as long as this pull request remains open (such as #662) and I'm reasonably certain that my mind is made up to merge these repositories.

[ocharles]

I wish I had noticed that this has lost all history of these repositories :( It's a shame, and it would have been possible to retain that with tree rewriting on the original repositories when merging them into here.

[Gabriella439]

@ocharles: Yeah, that's my mistake. I agree that it would have been better to preserve history but I spaced out when merging them in

Also, to be totally pedantic, you don't need to do any tree rewriting to preserve history, but you do if you want the history to be useful by appearing to have been underneath a subdirectory all along.

If it's any consolation, the history was not that interesting. The vast majority of changes were just fixing downstream repositories to build against the latest version of dhall