moss: Enable cobble-plugin so operations work on .stones directly

[ermo]

ermo
moss info linux-kvm-6.8.6-66-1-x86_64.stone <- what is the correct invocation for moss info to work for that?
or will only moss inspect ever work for that purpose?
because if moss info is not supposed to work on arguments ending in .stone, it might be nice to have moss suggest to use moss inspect or simply doing that instead?
Also, I would like to be able to do a moss extract some.stone to a folder, without having to create a .moss/ dir. Is this equivalent to having an alias for moss install --to?
use case: I want to inspect the initrd from the kernel .stone I just built, before I push it to prod. I don't want to do a full .moss/ root for this initially.
$ moss install --to /tmp/linux-kvm/ linux-kvm-6.8.6-66-1-x86_64.stone
Error: install: client: db: diesel connection: Unable to open the database file
oh fuck off and just do it, will you moss?!
(sorry for the outburst, was just trying to do my due diligence before pushing)
Ikey Doherty [BST/UTC+1]
So tldr we need cobble working
And for local arguments only prevent initialisation of system plugins
Right now you need to use a local repo as I never bothered to finish porting cobble
It's not actually "hard" to do tbh
ermo
expected difficulty/annoyance level?
Because if it's not hard, I'd love to have the ability to do the above.
Ikey Doherty [BST/UTC+1]
Basically we need access to the cobble plugin api via client and "preload" the stones into memory
Basically a metadb in ram
Then we convert the input .stone paths into their package::Id
Tldr we take our input args, filter out which end with .stone and exist
If remaining args is non empty, initialise other system plugins too
ermo
and this applies to which operations?
like, would it also work for info?
Ikey Doherty [BST/UTC+1]
For install op, always init all plugins
Then from all paths map the vec to package::Id via client.sideload()

ermo
like, would it also work for info?

Ya
Tbh info should only init system plugins (non cobble) when it has args that aren't valid .stone paths
Then apply that logic to install, and extend to map those paths to package::Id and inject into normal install workflow
Minimally disruptive

[ermo]

@tarkah Assigning to you so you can ask Ikey for extra guidance if the above is not enough?

[ermo]

Just to clarify:

I am expecting info, inspect and extract to work without a -D <.moss root> argument, so they are trivial to use when inspecting .stones after building them. IDC if the logic creates an ephemeral, secure /tmp/.moss-<random id> and silently uses that for its DB stuff if that's necessary for the listed operations only.

I fully understand that installing a .stone (i.e. the "sideloading" use case) requires a target root to install it into, and thus requires the user to specify moss install some.stone -D <some valid .moss/ root>

Cobble is about convenience.