Submit to GNOME Software as a plugin

[orowith2os]

Currently the software center is its own thing, as Nix functions differently from a normal package manager in many ways. However, I feel it would be ideal to instead make a plugin (possibly on top of an abstraction) and work with GNOME Software devs to allow it to work better with a plugin of this type.

[vlinkz]

I did try once in the past but didn't manage to get it to work, however perhaps if built on top of nix-data it could be done. I mainly made a separate app because it allowed me to more easily and tightly integrate functionality with Nix, and was also able to make it manage packages without Appstream metadata, unlike GNOME Software. I do agree that having Nix support in GNOME Software would be great and am definitely willing to take another crack at it when I find the time!

For reference for anyone reading this issue, I would say some good resources to start developing a GNOME Software plugin would:

• Documentation describing how to use a Rust library in C: https://docs.rust-embedded.org/book/interoperability/rust-with-c.html
• Rust library for querying and managing Nix metadata: https://github.com/snowflakelinux/nix-data
• Example rust wrapper for Nix into more conventional package management standards: https://github.com/snowflakelinux/snow

[eyome]

It would be amazing!

[davidak]

I think the most elegant solution would be PackageKit support in Nix, so it would work with GNOME Software, KDE Discover and any software that supports that API.

There was work in the past and i think @vlinkz also tried to get it working. Have you documented somewhere what the problems are and what would be the next step on that approach?

https://github.com/NixOS/nixpkgs/issues/15932 (do you have this solved?) https://github.com/NixOS/nixpkgs/pull/94055 https://github.com/NixOS/nix/issues/233 https://bugs.freedesktop.org/show_bug.cgi?id=76810 https://github.com/PackageKit/PackageKit/tree/767260e7c290cc44496f46b086de7368d44ff1b7/backends/nix

[vlinkz]

There are a few issues with packagekit at the moment that make using it with Nix less than ideal. Namely the daemon constantly crashes, and removing software has never worked for me. Regardless I think that packagekit wouldn't be the best option since having something that works on systems other than just NixOS would be preferable.

NixOS/nixpkgs#15932 (do you have this solved?)

Yes, kind of. I have https://github.com/vlinkz/nixos-appstream-generator, which as its name suggest generates appstream metadata for nix packages. It still is in a very early stage (but it does work!) and doesn't have any sort of automation yet.

I have kind of changed my mind on this as Nix and Flatpak both grow more popular. Having a single app that supports both would be the best option. I plan on writing a interface based on https://github.com/snowflakelinux/snow that would be able to be used in a GNOME Software plugin. However I'm still unsure how to make the GNOME Software plugin myself, so any help would be appreciated!

[eyome]

I have kind of changed my mind on this as Nix and Flatpak both grow more popular. Having a single app that supports both would be the best option. I plan on writing a interface based on https://github.com/snowflakelinux/snow that would be able to be used in a GNOME Software plugin.

God, make it true!

[Grafcube]

I plan on writing a interface based on https://github.com/snowflakelinux/snow that would be able to be used in a GNOME Software plugin.

I'm interested in contributing to SnowflakeOS and figured I would start here. When you say "writing an interface" do you mean using some API to make Gnome Software provide the features that Nix Software Center currently provides (edit configuration.nix and rebuild, run without installing etc.)? I wasn't able to find any docs on how to do that so some links would be appreciated. I didn't even know that was an option, I thought that packagekit was the only way. Or do you just mean patching the app?

[vlinkz]

I'm interested in contributing to SnowflakeOS and figured I would start here. When you say "writing an interface" do you mean using some API to make Gnome Software provide the features that Nix Software Center currently provides (edit configuration.nix and rebuild, run without installing etc.)? I wasn't able to find any docs on how to do that so some links would be appreciated. I didn't even know that was an option, I thought that packagekit was the only way. Or do you just mean patching the app?

There was an effort in the past to make packagekit work with Nix, but I personally don't think that would be the best way to go, as packagekit can be limiting, and I believe would prevent other systems already using packagekit from using Nix. I think the best way would be a plugin for GNOME Software similar to that of flatpaks or snaps. Such a plugin would need some way to manage Nix packages, which I think could be done using parts of snow (for installing/removing/upgrading packages) and nix-data (for getting metadata such as package versions, compatibility, etc).

So pretty much by interface, I mean some program (probably in rust so that it can use snow and nix-data directly, but having C headers) that can be called by a new plugin for GNOME Software. The first step would likely be to create that backend that everything else could be built on top of (pretty much a library version of snow).

[Grafcube]

I think the best way would be a plugin for GNOME Software similar to that of flatpaks or snaps. Such a plugin would need some way to manage Nix packages, which I think could be done using parts of snow (for installing/removing/upgrading packages) and nix-data (for getting metadata such as package versions, compatibility, etc).

I actually managed to find those plugins yesterday which led me to this link. I spent some time trying to implement these examples but there were several differences. After reading the headers I finally managed to get it to compile and Gnome Software did actually try to load it. But then it failed because of an undefined symbol. So I would say the main issue here is that documentation is basically non-existant (either that or I just couldn't find more up to date docs). I got a bit tired of trying to study the other plugins for clues. I might have a better shot if I ask on the Gnome Matrix but that will have to wait for a couple of weeks at least since I'll be too busy to work on this.

So pretty much by interface, I mean some program (probably in rust so that it can use snow and nix-data directly, but having C headers) that can be called by a new plugin for GNOME Software. The first step would likely be to create that backend that everything else could be built on top of (pretty much a library version of snow).

While I do love Rust, in this particular instance, it might not be a good idea. I think using Rust would probably prevent the plugin from being upstreamed, but I could be wrong.

Edit: Vanilla OS also has a fork with a meta plugin, which could also be useful as a reference, since its usage is similar. https://github.com/Vanilla-OS/gnome-software/tree/main/plugins/vanilla-meta

[orowith2os]

I think using Rust would probably prevent the plugin from being upstreamed, but I could be wrong.

It would be worth asking the developers themselves to see their thoughts on it. I see no reason why this couldn't be an external library that GNOME Software then loads in as a normal C library.

In other words: Rust lib -> C ABI -> C headers -> C gnome-software plugin -> GNOME Software

Maybe I'm laying it out an unnecessarily complicated way, but that would probably work. Hell, it's probably even similar to how Flatpaks are handled; from what I can tell, the Flatpak plugin utilizes libflatpak in this same setup.

[Grafcube]

So if I'm understanding you correctly, you're suggesting that the "util" part that many other plugins have, can be implemented in Rust and the C part of the plugin can check for a dependency and initialise if it exists? I think that's a good idea and in fact, as you said, there's probably no problem at all upstreaming it, since flatpak also depends on an external library.