[opinion?] is this the right use case for snaps?

If possible, I would love the community opinion on something. I almost have a snap done for a budgie applet (budgie desktop extension essentially). Which in some ways is a type of glue code (not an entire app -does not run in its own). And even had to reside in a specific location (budgie requirement). Some of the dependencies are not snap (the desktop). Also, do you feel that this is the right way to go for something like applets? It’s definitely not the traditional thing. The way I look at it is then we could share in theory these applets with Solus (although I know Ikey will probably just rebuild them native). It’s also really fast to package and rebuild once you hook them into git. We can iterates on them at any point we want through the Ubuntu life cycle. No freezes, etc. No need to package and push to debian. So there are definitely Pros. I’m just wondering if its still the right way. I guess it’s simply because no one (to my knowledge) is using snap packages in this way. I’m just being cautious to ensure we (Ubuntu Budgie) are doing this based on technical merit vs using the new “hot and shiny”. Haha. What are your thoughts. I’m all in on snaps, but this one use case, I’m not sure. And then I get hung up, is it really a pro to not push to Debian? Sure, it’s easier…

I’m building or either way, even if it’s just for the experience.

Thoughts?

Can you share what this looks like? How are these run?

Completion helpers come to mind as precedence. They are shell plugins that run confined.

Aside from not needing to do the packaging, you also don’t have to support old versions you can’t update anymore. So that’s a also pro in my point of view.

I’m missing on my way out the door to work, I’ll get you something once my meetings have settled.

1 Like