Extending ReqPack

Extending ReqPack

Prev: Troubleshooting | Home | Next: Choosing an Extension Model

This section is for developers who want to add new ecosystems, custom package sources, or ReqPack-native packages. Extension work in ReqPack happens at several different layers: plugin behavior, registry distribution, native rqp packaging, and core C++ internals.

ReqPack supports several extension styles. They are not equivalent. Choosing the right one early saves a lot of work.

Extension Models at a Glance

Model	Best for	Typical implementation
Lua wrapper plugin	wrap an existing package manager	plugins/<name>/run.lua bundle
Lua proxy plugin	route a logical ecosystem to real backends	plugins/java/run.lua style
Registry entry	distribute existing plugins centrally and attach trust metadata	registry JSON + existing plugin source
Native rqp package	package your own artifacts for ReqPack-native install/remove/update	.rqp package + repository index
Native C++ plugin	deep integration, performance, or non-Lua runtime needs	modify ReqPack source, implement IPlugin, rebuild binary

Registry entries are distribution and trust layer. They do not replace plugin implementation. Native C++ path is source-level work inside ReqPack, not a drop-in shared-library plugin model.

Recommended Reading Path

1. Choosing an Extension Model
2. Writing Lua Plugins
3. Lua Plugin Cookbook
4. Testing Lua Plugins
5. Building Registry Entries
6. Building rqp Packages and Repositories
7. Building Native C++ Plugins

What You Can Extend

• Add a new package-manager wrapper such as pipx, cargo, or an internal CLI.
• Add a proxy system such as java, which resolves to maven or gradle.
• Publish wrappers through a Git-backed registry.
• Publish native packages and repos through rqp.
• Add custom repository definitions that plugins consume at runtime.
• Implement deeper native runtime behavior in C++.

Best-practice Order

If you are not sure what to build, use this order:

1. Start with a Lua wrapper plugin.
2. If you want central distribution, add registry metadata and hashes.
3. Add resolvePackage() if you want stronger audit/SBOM behavior.
4. Add proxy support only if one logical ecosystem maps to multiple real ones.
5. Move to a C++ plugin only if Lua becomes a hard limitation and you are willing to rebuild ReqPack.

Related Pages

• Choosing an Extension Model
• Writing Lua Plugins
• Lua Plugin Cookbook
• Testing Lua Plugins
• Building Registry Entries
• Building rqp Packages and Repositories
• Building Native C++ Plugins

Prev: Troubleshooting | Home | Next: Choosing an Extension Model