Some thoughts on package provider actions

[kraileth]

Right now Comtrya seems to have 6 functions that are generally implemented with each provider:

• available()
• bootstrap()
• has_repository()
• add_repository()
• query()
• install()

Not all providers need each function: Some use stubs as long as actual code has not been written, some keep placeholder functions as they are actually not applicable to every provider. As we're seeing an increase in providers available the question arises: Could this be solved in a better way? For example simply leaving out functions in the providers and having a catchall in mod.rs that fails with some text like "Error: Provider X does not implement function Y!".

This should probably be decided upon before discussing which new functions might make sense to be introduced. Because right now adding one new function would probably mean at least adding a stub to every provider. This makes implementing optional or even unique features much more work than it has to be.

Two actions that come to mind immediately would be:

• package.remove
• package.update

One thing that feels strange with Comtrya is that the action names do not actually hint that they are idempotent! I would much prefer if that was visible by talking about states. What I mean would be e.g. this:

• package.installed instead of package.install
• package.absent instead of package.remove
• package.latest instead of package.update
• etc.

While it's probably early enough to make invasive changes, I'm not sure it would be justified in this case. But maybe we could introduce aliases (some already exist, right?).

Another issue that I thought about it the current behaviour of bootstrap: It's done automatically if required. With more cross-platform providers it may not be desirable to assume the default provider and just do the bootstrap. Maybe I wanted to use Linux Brew on Arch rather than bootstrapping Yay? Or Pkgin on macOS instead of Brew? Or Ravensw instead of BsdPkg on FreeBSD? I would kind of prefer package operations to fail on systems where the default packaging system is not available and would need to be bootstrapped explicitly first: action: package.bootstrap Maybe "auto bootstrap" could be a config option in the future?

And finally we could start collecting ideas for useful new package functions, both common and unique. For two examples of the latter (i.e. not available in other / most packaging systems):

• package.purge (think apt's distinction between removing and purging where the latter will also remove things like configuration which the former keeps)
• package.create (bsdpkg has the ability to re-create a proper package from already installed packages which can be nice before updating if the original package has been cleared from cache)

I'd like to see some brainstorming on which actions could be useful to have and what providers they would apply to.

[martintc]

To handle functions that just act as stubs because it isn't implemented or not applicable, we could refactor to return Err Option Enums, if an option returns error, display a message like suggested above. If it returns sum, unwrap the return or success.

Just a quick thought on implementation. May come back and comment more as I read through the rest.

[rawkode]

I left a comment on #157