Extending ReqPack

Extending ReqPack

Prev: Using Native rqp Packages | 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>/<name>.lua
Lua proxy plugin	route a logical ecosystem to real backends	plugins/java/java.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. Building Registry Entries
4. Building rqp Packages and Repositories
5. 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
• Building Registry Entries
• Building rqp Packages and Repositories
• Building Native C++ Plugins

Prev: Using Native rqp Packages | Home | Next: Choosing an Extension Model