Community plugin contributions & versioning

[Kirottu]

So there are a few things that should be addressed as Anyrun becomes more popular and more users & developers flock in.

The first of them is community contributed plugins. Adding them into the main repository in the long term is probably not feasible, some of them may be specialized and not really something the average user may need. They are also a maintenance burden where generally the maintenance of the plugins falls on me to handle after they've been merged, even if I am not that experienced with the codebase of the plugin.

The second issue is versioning. The approach of just making everyone use the latest code at all times (like anyrun-git on the AUR) has worked fine-ish for now but with more complexity and moving pieces, the risks of something breaking down accidentally is much higher and could affect well, everyone who keeps their system up to date. There are a few ways to go about this:

• Versioning Anyrun and all the plugins included in this repo with the same version number, and all bumped simultaneously. This would be easier regarding packaging and maintaining as everything would basically continue as they would continue as they already have.
• Versioning (and hence also packaging) each plugin and Anyrun separately, so plugins can get updated at their own pace and target a version of Anyrun.

I would really appreciate any feedback and suggestions on this matter, so any ideas you may have are welcome in this discussion.

[abenz1267]

For more general plugins, . F.e. my websearch plugin or the hyprlandwindows one, having them in the main repository seems fine to me.

Regarding maintenance: i think you could just handle this differently. F.e. i honestly don't come looking at the issues here, unless i have an issue or suggestion. What you could do is:

• issues regarding plugins must include a mention of the original author. Maybe even add a comment with the original author to the lib.rs so one can quickly see who did it.

Just today i noticed someone is having an issue with the websearch plugin. At the same time i also noticed you've changed it. Which is of course fine. So what would have been the process here, if it wasn't in the main repo? You forking my plugin from my repo, making a PR? The issues itself would hopefully have gotten reported to the source-repo of the plugin.

How would such plugins be distributed properly without being cumbersome to discover and install etc?

Also: i think it's much safer to have plugins in here instead of wherever. If a plugin gets abandoned for whatever reason, that could become a pita. You end up getting forks of forks of forks. I'm not sure if i'd go down that path.

[Kirottu]

Another option for the plugins would be a repo like anyrun-contrib that would have the community contributed plugins, where their authors could be listed in some way so that they could be contacted in case problems arise.

As for the distribution of plugins, with this the anyrun-contrib plugins could be distributed in another package.

[abenz1267]

Yes, i thought about that option as well. Might eventually be the most sensible one. Also: if there's consensus plugins could move from anyrun-contrib to anyrun. Maybe. Maybe not :D.

[NachtaktiverHalbaffe]

Just seeing this pinned issue. The Home Assistant project uses manifest.json files for the integrations, where also the code owner/maintainer is included. AFAIK they managed to integrate it into Github issues that the maintainer is automatically added to an issue and mentioned when a issue to that integration is opened.
Maybe this could be a starting point, a manifest file with the maintainer, compatible versions, deprecation warning etc. to the plugin and integrating it into the Github workflows and some infromative measures like deprecations warnings in the application itself.

Also longterm I would recommend to ensure that the included plugins have some maintainer (intentionally the creator, but can also be you if you are willing to be the maintainer) who is "responsible" for keeping that particular plugin working. If the maintainer leaves the plugin abonded and no new mainainer is found when problems occur then remove the plugin. Theres no point of a having a broken plugin in the repo if it cant be maintained (and the burden of maintanance of external contributed plugins shouldnt fall automatically on you if you cant or dont want to maintain it by yourself).

Otherwise I would prefer to have the plugin in this repo, maybe creating some guidelines that updates due to issues etc. are done through PR of branches which gets created and used for issues until they are resolved.

All of this is of course my point of new, I'm still on a junior level when it comes to programming and OSS and Rust isnt my domain

[Sntx626]

I'm heavily leaning towards putting the plugins into a seperate repo (all of them).

The overall process for us would look like this:

1. Define how plugin repos should look like (maybe provice an official template repo)
2. Put plugins into seperate git repos (potentially maintained by others)
3. In the main repo: have a file (entry) linking to them with a name, brief description and maintainers

If a plugin lost it's maintainers or is broken/insecure it's entry could easily be removed from the main repo. The plugin would then need to maintain itself.

Installing plugins from nix would still be trivial, if they're flakes themselves.
Though every plugin would need to maintain it's own, seperate packages (nix, aur, ...).

I'm willing to setup an example project, if there's interest for it.

PS: At least for me it would make the workflow and iteration on plugins really easy. Furthermore I think it's a good way to satify seperation-of-concerns, since this will also make it easy to go the other way around and replace the core anyrun with let's say an anyrun-tui.

---

Sidenote:
I don't think it's a good idea (because of complexity), but we could also add them to the main repo via git-submodules.

[Kirottu]

@NachtaktiverHalbaffe I don't think an automated system with manifest files like that would really be that feasible, due to being quite complex and out of the scope of this project. But in general who maintains the different plugins should ideally be made pretty clear.

As for placing everything in separate repositories like @Sntx626 suggested, it would make dealing with who maintains what and versioning much easier but installing stuff may be more complicated and the project would be more fragmented. For the "official" plugins made by me, I could create an organization to group all of the repos in the same place on GitHub, and then of course link all the other plugins in the main repo readme. It would be a bit of a chore to convert to that form, but it would probably be sustainable given that we also figure out how to do packaging properly.

If you feel like making an example project template that would contain all the relevant info (about maintainer, version support, etc.), I'd like to see it.

[Sntx626]

I'll cook up an example.

[Sntx626]

I've put together this example github organisation.
And checked it can be build and used, by adding it to my system config (c.f. this diff).

Please keep in mind that this is rather proof-of-concept and nothing final.
I've also changed some parts more than they might need to have been changed...

If you like it that way we can talk about how we'll realise it for the real anyrun.
I intend to delete the repos/org once we've deciced and possibly transitioned.

Feel free to ask questions if things aren't clear.

[Kirottu]

The descriptions of the "core repositories" in the org README are not exactly correct, but otherwise that structure does look pretty nice to me. How does everyone else feel about that template?

Aside from deciding on the final structure, contribution guidelines (issue templates, how to add plugins to the plugin list, etc.) should also be created to make this all a lot more manageable.

[Sntx626]

Yes, the readme looks better, than it is accurate. It's written by our favorite artificial intern, since I didn't want to invest too much time on secondary details and focus on the structure / getting it to work.

Though I should mention that one of the bigger changes I made was in terms of dependencies.
anyrun_plugin has solely become a template repository for new plugins. All plugins no longer depend on anyrun_plugin, but rather on anyrun_interface and anyrun_macros directly (thinking about it, I should replace the src/lib.rs in anyrun_plugin with the example plugin code from anyrun's readme).

How should we proceed?

1. Does @Kirottu create a new organization with a proper name (anyrun seems to be taken) and invite us to work on it? Or do we keep the current organization, change it's name and I invite @Kirottu and anyone interested in working on it? (After we're done we should probably also replace the anyrun repo with this one to preserve the commit history).
2. Do we create a github project (or something similar) to track the missing tasks, or do we stick to discussions in this issue?
3. Whats the plan for the contribution guiidelines?
   1. @Kirottu do you have anything specific in mind / an example of a repo doing it "right"?
   2. What do other think?
   3. Do we enforce GPLv3 for all plugins listed in the org?
   4. ...
4. Document what's been changed over the current anyrun
5. Do we want to support core plugins directly in the org (as it is the case right now)?
   1. What plugins are core-plugins, what plugins should be moved out?

[abenz1267]

This looks super fine to me, nothing to add really.

Do we want to support core plugins directly in the org (as it is the case right now)?
What plugins are core-plugins, what plugins should be moved out?

I think core plugins should be supported, simply to have a solid OOTB experience. But what could be considered a core-plugin and what not? How to decide? Maybe adoption could be a factor. As in: if 99% of the user-base uses a certain plugin, it should prob. be considered a core-plugin. But this required gathering data somehow...

[Kirottu]

Though I should mention that one of the bigger changes I made was in terms of dependencies. anyrun_plugin has solely become a template repository for new plugins. All plugins no longer depend on anyrun_plugin, but rather on anyrun_interface and anyrun_macros directly (thinking about it, I should replace the src/lib.rs in anyrun_plugin with the example plugin code from anyrun's readme).

I would rather preserve the anyrun_plugin create, as with some of the suggestions in other issues there is room to add more functionality in that crate to reduce code duplication.

Does @Kirottu create a new organization with a proper name (anyrun seems to be taken) and invite us to work on it? Or do we keep the current organization, change it's name and I invite @Kirottu and anyone interested in working on it? (After we're done we should probably also replace the anyrun repo with this one to preserve the commit history).

I think that makes the most sense, this repo can be transferred to that org in that case and the required modifications could be made. I could create a clone of this repo under my account that can be archived.

Do we create a github project (or something similar) to track the missing tasks, or do we stick to discussions in this issue?

That is a solid idea to keep track of things, I am notoriously bad with forgetting about things I need to do so having all the stuff that needs doing in one place seems like a good idea.

Whats the plan for the contribution guiidelines?

For the guidelines I was thinking about issue/PR/plugin templates and general guidance as to how to do things like where issues should be reported, how to submit a plugin into the project (to be added in a list of plugins).

Do we enforce GPLv3 for all plugins listed in the org?

I prefer to have my code licensed with GPLv3, but I really am not that experienced with licenses and how to deal with them so I don't have that much to say about it. If the plugins in the org are the "core" plugins, which would likely mean that the majority are maintained by me it would make sense to just have all of them under the same license.

I think core plugins should be supported, simply to have a solid OOTB experience. But what could be considered a core-plugin and what not? How to decide? Maybe adoption could be a factor. As in: if 99% of the user-base uses a certain plugin, it should prob. be considered a core-plugin. But this required gathering data somehow...

Gathering user data isn't really going to be a feasible option so I'd say we just promote all the plugins that are currently in the main repo to core plugins (except maybe for randr as it is a bit too incomplete to properly fit that, as it only supports Hyprland) as all of them seem generic enough.

Also with the separation of the crates, versioning should be established (everything can start at 0.1.0) and the crates that will be used by plugins and Anyrun should be published on crates.io. This will make compatibility easier to track as well, as the only relevant version for compatibility is the interface crate version.

[Sntx626]

I would rather preserve the anyrun_plugin create, as with some of the suggestions in other issues there is room to add more functionality in that crate to reduce code duplication.

Ok, in that case I'll revert anyrun_plugin back and instead create anyrun_template_plugin as a template repository. I think that should go with a renaming of the plugins. The main repo is an exception.

• Main repo: anyrun
• Anyrun modules: anyrun_<module-name>, i.e. anyrun_interface, anyrun_macros & anyrun_plugin
• Anyrun plugins: anyrun_<plugin-name>_plugin, i.e. anyrun_applications_plugin, anyrun_dictionary_plugin, anyrun_template_plugin,...

I think that makes the most sense, this repo can be transferred to that org in that case and the required modifications could be made. I could create a clone of this repo under my account that can be archived.

Just to avoid misunderstanding: You want to keep the current organization and modify it?
In that case I'll invite you.

That is a solid idea to keep track of things, I am notoriously bad with forgetting about things I need to do so having all the stuff that needs doing in one place seems like a good idea.

We can create a project for that in the org.

For the guidelines I was thinking about issue/PR/plugin templates and general guidance as to how to do things like where issues should be reported, how to submit a plugin into the project (to be added in a list of plugins).

This sounds great and reminds me of the way nixpkgs handles it (though they've mastered it).
We could draw inspiration form there.

I prefer to have my code licensed with GPLv3, but I really am not that experienced with licenses and how to deal with them so I don't have that much to say about it. If the plugins in the org are the "core" plugins, which would likely mean that the majority are maintained by me it would make sense to just have all of them under the same license.

Sounds good.

Gathering user data isn't really going to be a feasible option so I'd say we just promote all the plugins that are currently in the main repo to core plugins (except maybe for randr as it is a bit too incomplete to properly fit that, as it only supports Hyprland) as all of them seem generic enough.

For simplicity's sake I also say that we should stick with just deciding it for the current plugins.
And I agree that randr should be moved to the community plugins.

Also with the separation of the crates, versioning should be established (everything can start at 0.1.0) and the crates that will be used by plugins and Anyrun should be published on crates.io. This will make compatibility easier to track as well, as the only relevant version for compatibility is the interface crate version.

We should defintely reference to semver.org, the versions would then be tracked through the Cargo.toml of the respective plugins.

Pushing the main repo and anyrun modules to crates.io/lib.rs would also result in the plugins Cargo.toml dependencies for them to no longer point to the git repo and instead to the "published" version.