Split Swarm components into libraries

[xsebek]

I propose we split the sources into Cabal libraries.

Practical problem: compilation

When I run tests after changing some Swarm.Language modules, every Swarm source file (60+) is recompiled.

However, we do not need to compile LSP or TUI or Web API, because we do not test them.

Theoretical problem: dependencies

We mostly* avoided using TUI or Web dependencies in the code for language and game logic.

In theory, we could switch the dependencies for new ones or add another UI without changing the game or language code.

Left unchecked, the dependencies could slowly leak and make future experiments less viable.

At least it would be easier to see which dependencies are needed for what part of the Swarm application.

Solution

In my mind, Swarm code is split like this in order of dependency:

• Swarm.Language
  • Swarm.Language.LSP (move to its own directory?)
  • Swarm.Game
    • Swarm.DocGen (not really required in the final application)
    • Swarm.TUI
      • Swarm.Web

Swarm.App is just a small module to neatly initialise everything in order.

There is also Swarm.Version, which has a failure type that we use in TUI to show it nicely.
We could split off the failure type and use the network call and Git polling only in App.

---

_{*) except for Brick AttrName in Swarm.Game.Display.}

[byorgey]

Makes sense to me, as long as we continue to have everything in a single repository.

[xsebek]

@byorgey repository definitely stays the same. 🙂

The simple idea is to make directories directly in src libraries to get a small compilation speedup and a good feeling from doing The Right Thing ™️

[kostmo]

If you're going to start on this, I wonder if we could please merge #873 in a partially-complete state first, since the merge conflicts would probably be massive.

[xsebek]

@kostmo good point. I think we can try another approach first.

I will take file content changes out of the PR and merge them separately.

If I am patient enough with that, then the final PR will be only moving files into subdirectories and the cabal file.

[byorgey]

@xsebek I'm curious what your thoughts are on this now. We had #1069 but then you closed it and I'm not sure why. (If it's because you didn't get enough response/reviews, sorry about that!) I still think this could be a good idea, though I'm still not totally sure I understand all the implications.

[xsebek]

@byorgey not at all! 🙂 It was simply taking time to rebase the PR, given that it moved around lot of code.

I think this is a good thing ™️ to do, but needs a concrete immediate use-case. For example deciding that LSP client/Doc generator or some other part should be moved into a separate executable and depend on "swarm the language" library. Then the short term annoyance of investigating what could be broken by this change should get outweighed by the benefits. 😅

[kostmo]

Would it be more feasible (with regard to rebasing) to tackle one sub-library at time (i.e. peel off one library per PR)?

For starters, perhaps just the Swarm.Util module could be separated and used as a testbed for separating more libraries.

[byorgey]

Yes, that sounds very reasonable to me.