packages: add `brew` and `snap` backends

[zheltikov]

Hello!

For systems where the snap and brew package managers are installed (apart from apt) it would be useful to have blocks that show available updates for those package managers too. The preferred configuration for these blocks would be practically identical the config of the apt block, excluding the block name obviously.

To list available updates for snap, you can run: $ snap refresh --list To list available updates for brew, you can run: $ brew outdated

Some preferred icons for each block would be:

• snap: "🐦" or "📦"
• brew: "🍺"

Thanks!

[MaxVerevkin]

I wonder if it would be a good idea to merge all package blocks (apt, pacman, ...) into one since they all have a very similar config and structure.

[zheltikov]

Probably we should create a new "updates" or "packages" block, with the ability to configure "backends" for it. Configuration would be like so:

[[block]]
block = "updates"
format = " $icon $count.eng(w:1) "
format_up_to_date = ""
package_manager_backends = ["apt", "pacman", "brew", "snap"]

This block would then aggregate data from all the backends configured... @MaxVerevkin, thoughts on this approach?

[IshanGrover2004]

Probably we should create a new "updates" or "packages" block, with the ability to configure "backends" for it. Configuration would be like so:

[[block]]
block = "updates"
format = " $icon $count.eng(w:1) "
format_up_to_date = ""
package_manager_backends = ["apt", "pacman", "brew", "snap"]

I guess this will make some massive change in code structure. Is this OK? @MaxVerevkin

I am thinking to break down to two PR: 1 for snap and brew and another PR maybe if you approve the above then I'll try that in another PR If this is Ok,then i'll start working on this Any other suggestion?

[MaxVerevkin]

I am thinking to break down to two PR: 1 for snap and brew and another PR maybe if you approve the above then I'll try that in another PR

It may make sense to do the latter first to reduce duplicated work, but this isn't required ofcourse.

I guess this will make some massive change in code structure.

Sure, that's okay. And this doesn't have to be a breaking change for users. I thought about having blocks/packages/{apt.rs,pacman.rs,...} (containing only package manager specific code) and then reusing them in current blocks, which would become deprecated.

[IshanGrover2004]

I thought about having blocks/packages/{apt.rs,pacman.rs,...} (containing only package manager specific code) and then reusing them in current blocks, which would become deprecated.

Yeah, this is exactly what i thought to do. So, i'll try to implement the above suggested idea.

[IshanGrover2004]

Hey @MaxVerevkin , I was trying to solve this issue but I am stuck at some place:

• let's suppose i opt for package_manager = ["apt","snap","pacman"] Now what should be the format supported to show the info of update Is this good: format = "$icon $apt + $snap + $pacman" or something else in your mind

• Do we need to set any package manager default, if this field is not provided. I know, it doesn't make sense to set any package manager default but I thought to make sure about it.

I'll make PR soon when my base model is ready or maybe when I am really stuck somewhere where i need code review for maintainers.

[MaxVerevkin]

• let's suppose i opt for package_manager = ["apt","snap","pacman"] Now what should be the format supported to show the info of update Is this good: format = "$icon $apt + $snap + $pacman" or something else in your mind

This seems good, considering pacman already has something like this with "pacman", "aur" and "both".

• Do we need to set any package manager default, if this field is not provided. I know, it doesn't make sense to set any package manager default but I thought to make sure about it.

Yeah, we can just make it a required parameter. Or maybe we can infer which package managers should be used from the format option (but still leave the package_manager option because someone may just use " $total ").