swarm-game / swarm

Resource gathering + programming game
Other
838 stars 52 forks source link

Split Swarm components into libraries #1043

Closed xsebek closed 6 months ago

xsebek commented 1 year ago

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.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 commented 1 year ago

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

xsebek commented 1 year ago

@byorgey repository definitely stays the same. :slightly_smiling_face:

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 :tm:

kostmo commented 1 year ago

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 commented 1 year ago

@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 commented 12 months ago

@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 commented 12 months ago

@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 commented 12 months ago

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 commented 12 months ago

Yes, that sounds very reasonable to me.