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.

[jplatte]

More discussion in #218.

[jplatte]

Came to this from the packaging Matrix channel. I have an arch linux background; on arch you can install a package "just like that" and have found it useful for installing a self-built package (e.g. existing pkg modified with custom patch or completely new package) for testing, so just very temporary packages, but also for the use case of installing a patch "permanently", where getting it erased with the next update would be annoying. For the latter case you would usually also add the package name to /etc/pacman.conf under the IgnorePkg key, which causes pacman to never upgrade the package, but print a warning when updates are available.

I think moss install some.stone auto-pinning the package makes a lot of sense, if it's hard to forget about pinned packages. I would suggest having a warning like arch, on moss sync -u for when any packages are pinned and newer versions are available. This doesn't need to be verbose, it can just be a single line prefixed with a yellow Warning: to stand out, that lists the pinned-outdated packages.

Extra idea from ermo over on Matrix:

I think that maybe moss pin <an installed thing> could be hardlink_or_copy a .stone into the cobble repo then reindex it because then it'd be highest priority for all operations going forward. Similarly moss unpin <an installed thing> could be if the .stone exists in the cobble index, rm it then reindex.