LÖVE

Hello!

First of all, this is my first post here, so a big thank you to all the wonderful LÖVE community and developers is due!
Since LÖVE is powering our game development, it's only fair to contribute to its awesomeness.

Now down for the interesting part...

I created crush: a simple external library manager for LÖVE games/libraries, it's good for two things:

• Fetching libraries and including them in your project.
• Conveniently distributing libraries depending on other libraries themselves.

You can read more on that and how to use it in its code repo:
https://codeberg.org/1414codeforge/crush

Its distinguishing features are:

• Extremely predictable and easy to understand.
• Doesn't require large package manager à la LuaRocks.
• Doesn't require anything else but a single crush.lua file in your project and a .lovedeps file listing the required libraries.
• No fancy publishing procedure, just give your library a git repo and you're good.
• ...in fact it does work with most existing LÖVE libraries that aren't even aware of your crush
• It deals with just one task, and it doesn't plan to deal with anything more than that.

Enjoy! 'cause LÖVE is an easy game when you've got a real crush

The concept of this seems interesting at first glance, but after going over the README I'm not sure I understand what this brings to the table over just using git submodules. It's possible I missed something important, but could you expand on that?

Git submodules are perfectly fine for games and self-contained libraries, but fall short for libraries with dependencies.

For example, suppose there are 2 libraries:

• Utility library
• UI library (uses the utility library)

And a game project that relies on both of them.

Git submodule scenario

• The UI library bundles the utility library as a submodule
• The game bundles both the UI library and the utility library as submodules

The utility library code tree gets duplicated.
The situation escalates with more complex and nested dependencies.

crush scenario

By running: The utility library is bundled only once within the game, because common dependencies are detected.
The process is automatic, thanks to the .lovedeps file, so the experience is close to a typical Lua rock.
This enables sharing code between libraries and between games with zero duplication and no manual setup by the end library users.

Since external libraries always fall within the lib subdirectory, you don't need esoteric mumbo jumbo for require() paths either.
You can blindly: And be confident that crush fetched the external library and placed it there, whether you are writing the UI library or the game code.

You may think of crush as a disciplined git fetcher.
This was actually by design, since I don't appreciate sophisticated tools doing stuff behind my back.
I appreciate LÖVE simplicity and predictability, and don't want to see it change.

Ah, that's a good point! Hadn't thought of that.

In case anybody is interested, a library for user interfaces I've been working on recently, yui, provides a perfect use case for crush.
https://codeberg.org/1414codeforge/yui

As a matter of fact, it's what motivated it.

The situation with yui dependencies is:

• gear general utility functions library.
• moonspeak internationalization library.

moonspeak depends on:

• df-serialize a tiny library to convert Lua tables to text and back.

Now, gear, moonspeak and df-serialize are perfectly useful for other projects and for my own game. I don't want end users to duplicate them endlessly in their project for every submodule.
Nor I want them to track those nested dependencies manually.
And thus crush was born.

In yui's README I tried to explain how crush works in practice.

Update:

• We now have a new home: https://codeberg.org1414codeforge, contributing is now easier
• crush now provides a friendly message when Lua version is too old.

Main post was updated.