Introduce a package provider abstraction in Luumen to decouple package management from Wally and allow alternative implementations (e.g. future Luumen package client).
This is a foundational step to support multiple package backends while keeping a unified CLI (luu add, luu install, etc.).
Goals
- Standardize how Luumen interacts with package management
- Keep Wally as the default provider
- Allow future providers without changing CLI UX
- Define provider interface
Create a simple interface:
type PackageProvider interface {
Add(pkg string, opts AddOptions) error
Install(opts InstallOptions) error
Remove(pkg string) error
Update(pkg string) error
}
- Implement Wally provider
Create a WallyProvider that:
- Updates wally.toml
- Calls wally install when needed
- Handles add/remove/update flows using current Luumen logic
- Provider selection
Add basic provider selection logic:
- Default to Wally
- Allow future config support
Example:
[packages]
provider = "wally"
- Route CLI through provider
Update:
luu add
luu install
luu remove (if exists)
luu update (if exists)
So they call the provider instead of directly calling Wally logic.
Introduce a package provider abstraction in Luumen to decouple package management from Wally and allow alternative implementations (e.g. future Luumen package client).
This is a foundational step to support multiple package backends while keeping a unified CLI (luu add, luu install, etc.).
Goals
Create a simple interface:
Create a WallyProvider that:
Add basic provider selection logic:
Example:
Update:
luu add
luu install
luu remove (if exists)
luu update (if exists)
So they call the provider instead of directly calling Wally logic.