Welcome! ModuHub is the version manager for Modularity (also known as ModuEngine). It is a small standalone launcher that keeps track of your Modularity installations and your projects in one place: browse official releases, install as many engine versions side by side as you like, pin each project to the version it was built with, and launch the right editor with one click. The project is under active development. The core install/launch/pin workflow works today, but there are experimental areas and a few rough edges. We would rather be clear about those than pretend otherwise. Feedback, bug reports, documentation fixes, and any focused code contributions are all genuinely welcome.

ModuHub includes:

• Installed version management. Every Modularity version lives in its own isolated directory. Install, launch, repair, open the install folder, or remove a version, removal never touches anything outside that version's directory, and it refuses to delete a version a project is still pinned to.
• An online releases browser: backed by the official release feed. Releases are fetched on a background thread with platform-classified assets, download counts, logos, and full release notes. the UI never blocks on the network.
• A project manager: where you register (or auto-discover) your Modularity projects, pin each one to a specific engine version or let it follow your default, and launch it directly into the matching editor.
• A downloads tab: with a per-install pipeline view: download → extract → done, with progress and errors surfaced as they happen.
• Release notes with severity badges.: Notes are scanned for WARNING:, CAUTION:, EXPERIMENTAL:, DEPRECATED:, and UNSTABLE: tags so you can see at a glance whether a build needs extra care before you update.
• A familiar look and feel: ModuHub uses Modularity's font and theming, plus an optional intro animation and sound you can toggle in Settings.

How a typical workflow comes together

1. Launch ModuHub: and open the Online Releases tab. Releases are fetched from the official Tareno Labs repository automatically.
2. Install a version.: Pick a release, choose the asset for your platform, and ModuHub downloads and extracts it into its own directory under versions/<tag>/. Watch progress in the Downloads tab.
3. Register your projects: in the Projects tab, add a .modu project by path, or point ModuHub at a search root and let it discover them.
4. Pin versions where it matters.: Each project can be pinned to a specific Modularity version; unpinned projects follow your default version, so upgrading the default never silently changes a pinned project.
5. Launch.: ModuHub starts the right editor binary for that project's version and hands it the project path. The editor runs detached, so ModuHub stays out of the way.
6. Maintain over time.: Repair a broken install, remove versions you no longer need, and check release-note severity badges before jumping onto a new build.

Everything ModuHub manages lives under a single data root (~/.local/share/ModuHub on Linux, honoring XDG_DATA_HOME; %APPDATA%\ModuHub on Windows):

<root>/
  versions/<tag>/     ← extracted engine builds, mutually isolated
  downloads/<tag>/    ← archives in flight (or kept after extraction)
  hub.json            ← default version + per-project pinning

Build and run

Linux

ModuHub reuses the ThirdParty tree from a Modularity checkout (the ModuGUI ImGui fork, GLFW, glad, glm), so clone the two repositories side by side. The build script checks system dependencies, configures CMake, and builds:

git clone https://pak.moduengine.xyz/Tareno-Labs-LLC/Modularity.git
git clone https://pak.moduengine.xyz/Tareno-Labs-LLC/ModuHub.git
cd ModuHub
./build.sh
./build/ModuHub

Useful development builds include:

./build.sh --clean
./build.sh --build-type=Debug
./build.sh --modularity-root=/path/to/Modularity   # if it isn't at ../Modularity
./build.sh --run                                   # launch after a successful build
./build.sh --skip-deps                             # skip auto-install of system packages

Build requirements are intentionally small: between a C++14 compiler up to a C++17 compiler, CMake 3.16+, libcurl, X11, and OpenGL. Extracting downloaded engine builds shells out to the system 7z (or unzip/tar for those formats), so make sure 7z is installed, Modularity's release artifacts are .7z archives.

Project status and known limitations

ModuHub is usable, but it is still young. These are the important expectations to set before you dive in:

Area	Current status
Automated tests	There is no automated test suite yet. Changes are currently verified by building and running ModuHub against real releases.
Windows	The code carries Windows paths (%APPDATA% data root, Windows asset classification), but there is no build.bat yet and Windows builds are not routinely exercised. Linux is the established platform.
Archive extraction	Extraction depends on system tools (7z, unzip, tar). If none are available, installs will fail with a hint about what to install.
Severity badges	Release-note severity tags are informational only, they do not yet gate installs or quarantine releases.
Concurrent downloads	The maxConcurrentDownloads setting is reserved; downloads currently dispatch one worker per request.
APIs and file formats	The hub.json schema and settings format can still evolve. Call out compatibility changes in your pull request.

If you run into something not listed here, please open an issue. A screenshot, log excerpt, or the release tag that misbehaved can save a lot of guesswork.

Contributing

You do not need to arrive with a huge feature. Fixing a typo, improving a confusing error message, testing another distribution, documenting an edge case, or reducing a reliable crash is valuable work.

A friendly contribution workflow

1. Check the open issues or open a discussion issue before starting a large change.
2. Fork the repository and create a focused branch from main.
3. Build once before changing anything so you know your local toolchain and the Modularity ThirdParty path are healthy.
4. Make the smallest coherent change that solves the problem. Follow nearby naming and code style, and reuse the existing fetcher, install, registry, and UI helpers rather than adding parallel systems.
5. Keep the UI responsive: network requests, downloads, and extraction belong on worker threads, never on the ImGui frame loop.
6. Open a pull request explaining what changed, why it changed, how you tested it, and any known tradeoffs or follow-up work.

Before opening a pull request. Please ensure that:

• The change is focused and does not include unrelated formatting or generated build output.
• ModuHub builds and launches, and the install → launch → remove flow still works.
• Version removal safety is preserved: uninstalling must never touch files outside that version's directory, and pinned versions must stay protected.
• hub.json or settings format changes have been checked for compatibility with existing files.
• New behavior is documented, including experimental status or known limitations.
• Modifications comply with the project license.

Reporting a bug

Please include as much of the following as you can:

• Your operating system, compiler/toolchain, and the commit or build you used.
• Clear reproduction steps and what you expected to happen.
• What actually happened, including the full error message or console output.
• The release tag involved, when the issue is about a specific install or download.
• Screenshots or a short recording for UI issues. One reminder: No report has to be perfect. If you can reproduce the problem but are unsure where it lives, no worries! You can open an issue anyway and say what you already tried.

Repository guide

Path	What lives there
src/	The whole app: UI shell (ModuHubApp), release fetching/parsing, download manager, install manager, project registry, settings, and platform helpers
ImagePreviews/	Logos and imagery used by this README and the repository page
build.sh	Linux build helper (dependency check, CMake configure, build, optional run)
CMakeLists.txt	Build configuration; points at a Modularity checkout for shared ThirdParty libraries

License

ModuHub is distributed under the Tareno-Labs Community Use License 1.2. In short, you may build commercial or closed-source software with it and modify it. If you distribute a modified version, its corresponding source must remain available under the same license, and your modifications must be identified. The summary above is not legal advice; the full license text is authoritative.

---

❤️ Built with care by Tareno Labs™ and the Modularity community. ❤️
Questions, experiments, bug reports, and first-time contributions are welcome here.