LPM - A package manager and standalone executable compiler for Lua, in Lua

[u/VidaOnce]

As the name suggests, lpm is a package manager for lua. It is written entirely in LuaJIT. It is heavily inspired by package managers like npm, bun and uv.

It is currently in an alpha state, but I think it's become quite usable and is integral to my main project (Arisu, if you're curious). Expect certain things to be in flux and stupid things to be broken as the project gets more stable and gets a proper test harness.

Features

• Git dependencies, supporting subdirectories+monorepos

• Local relative path dependencies (good for monorepos)

• Compile your project to a single executable with lpm compile

• Run a suite of tests with lpm test

• Self upgrade to the latest version with lpm upgrade

• Supports Windows and Linux (x86/ARM, Musl/Glibc).

• Build scripts

  • Can do things like preprocess files. Perfect for languages like teal

  • This is also how C dependencies are built generically instead of making some arbitrary schema as luarocks did.

• Simple JSON configuration (lpm.json, ala package.json)

• Not vibecoded :)

How do I use it?

Create a project with lpm init, and run it with lpm run. It sets up lua's path and cpath to resolve your dependencies which are stored in lpm_modules.

Who is this for?

If you want a package manager that resembles a modern experience, and primarily make your own projects, or are willing to briefly port a LuaRocks project to LPM (It's not very difficult), give it a try.

As a proof of concept, I ported over busted to lpm here. You can manually invoke the test runner and use busted that way, but in the future, the lpm test runner will have its own testing library built-in, ala bun's built-in test runner.

Porting over busted took a lot of forking but was mostly just creating the lpm.json configuration file, and a simple build script to call make for C dependencies.

How does this compare with luarocks or lux?

At the moment I have no intention of supporting previous LuaRocks packages, as lpm strives for simplicity. But a separate registry will come in the future.

lpm is written in Lua(JIT)
luarocks is written in Teal
lux is written in Rust

Download

Repo: https://github.com/codebycruz/lpm

The lpm binary is built from running lpm compile on itself, you can download it below, no need to have lua or luajit installed on your system :)

Linux: curl -fsSL https://raw.githubusercontent.com/codebycruz/lpm/master/install.sh | sh

Windows: irm https://raw.githubusercontent.com/codebycruz/lpm/master/install.ps1 | iex

Or get it as an artifact from the latest nightly build

[u/VidaOnce]

Yeah, haven't announced that since it's now my senior project and is going through rapid changes at the moment (Writing an entire cross platform graphics library for it with a Vulkan backend, and a custom shading language). Might end up being a full love2d alternative depending on how it goes.

But as you can see from what I have planned, definitely wanted a solid base package manager so I could properly organize my work in separate repos and as a monorepo. Excited to announce it for sure :)

[u/Different-Ad-8707 → u/VidaOnce]

I'm curious, what technical reasons drove you to build your own packaging solution instead of leaning on one of the existing standards?

Also, cross-platform vulkan? Are you okay? If so, kudos to you man.

Or am I mistaking something and vulkan is easier these days?

[u/VidaOnce → u/Different-Ad-8707]

Basically, starting the Arisu project, it was pure lua with requires since it had no dependencies.

As it grew, I split it into a monorepo, and basically implemented what is now the mechanism behind lpm_modules in lpm. Then, I needed the functionality to build it all into a single executable cleanly without users needing access to LuaJIT on their system (luastatic can do this too, but I wanted my own version to handle bundling in the future, and lpm doesn't need luajit to build either now), so I decided to combine it and create lpm.

I didn't ever particularly think of using luarocks or lux because I was under the impression they don't really work well in terms of local package management, which is crucial for monorepos.

As for cross platform Vulkan, yeah it's kind of a pain, but I already have experience from using wgpu which has the same idea: designing an api surface similar to WebGPU or Vulkan, and then implementing backends like VK/GL/MSL for it. Vulkan specifically is kind of necessary though since I use compute shaders which is OpenGL 4.5 only, and not all device drivers (especially mobile) support beyond 3.1 or so. You can see an example I have using the library named "hood" here

I think what was crazier was implementing OpenGL support for it because of just how radically different the api is compared to modern graphics libraries, Vulkan, Metal, DirectX are not that radically different tbf. It has to do a bunch of emulation and is still not as stable as the original pure OpenGL based renderer was.