-
-
Notifications
You must be signed in to change notification settings - Fork 29
Description
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 onlymoss inspect
ever work for that purpose?
because ifmoss info
is not supposed to work on arguments ending in.stone
, it might be nice to have moss suggest to usemoss inspect
or simply doing that instead?
Also, I would like to be able to do amoss extract some.stone
to a folder, without having to create a.moss/
dir. Is this equivalent to having an alias formoss 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