Albert
Awesome albert plugins #1155
Replies: 5 comments 7 replies
-
|
Is it fine to have standalone repos linked by submodules, or would you prefer to have a separate copy maintained in the python repo? |
Beta Was this translation helpful? Give feedback.
-
|
Rather no submodules. See albertlauncher/python#129 (comment). |
Beta Was this translation helpful? Give feedback.
-
|
I think it would much easier on my end to just keep them as standalone repos. I find it much more organized to have a repo for each and be able to easily make immediate changes. I may consider contributing in the future, but for now, I'm leaning towards keeping it simple and not making a copy. In any case, I've been working to migrate plugins to work with 0.18 and it hasn't been as smooth as I had hoped. Hopefully, you can answer some of the things I got stuck on. To keep things organized, I opened some issues for my questions at https://github.com/albertlauncher/plugins/issues. |
Beta Was this translation helpful? Give feedback.
-
|
The organized structure is the only argument I can imagine pro submodules. It does not really outweigh the arguments I listed in the link above. I dont see the point in "easily make immediate changes". You have your forked repo where you can make changes as you like, right? In contrast we (me, the community, users, maintainers) are not able to make immediate changes to your repo without your intervention. Maybe, if thats what you intend to, this is good. But from a collaborative open source pov thats inconvenient (besides the unavailable github review feature). Of course you are free to not push your plugins. But I strive for an pragmatic, effortless solution to provide users cool plugins, which submodules are unfortunately not. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking if it's a fork I may have several branches for different features and I'd have to keep each one of them synced with the upstream constantly to have all plugins running the latest version locally assuming I use it as my primary copy. I also like being able to have issues related the plugin all in one place so I can easily see them and put out quick fixes. I'll probably open PRs for the plugins soon, but I still feel there may be better alternatives for plugin management. One of my concerns, however, is regarding allowing configuration. What would you consider the best practice for having data / configuration files for the plugin that the user can modify? Currently I keep a json file adjacent to the Python code, but I'm concerned that if it's in the official build, it might get overridden occasionally. Maybe there could be a default config and allow creating a separate file that gets merged? What location do you think would be best for storing it? |
Beta Was this translation helpful? Give feedback.
-
|
@DenverCoder1 regarding config: I made a sample poc https://github.com/Bierchermuesli/albert-ripe let me know what you think |
Beta Was this translation helpful? Give feedback.
-
|
In my mind one repo per plugin (documentation, Screenshots, HowTo, Install, Config, issues) makes more sense. Instead of using submodules, are there other approach to simplify core maintaining and user plugin installation? e.g. a install by git URL? a Store? or just a list https://github.com/albertlauncher/awesome-albert (add a row for compatiblity)? This way everybody can choose what plugins they need and who they trust. Why bundling plugins? e.g. I don't care much about a bitwarden, jetbrain, $OS-specific-plugin What about duplicates of plugins/triggers? Which of all dns, ip lookup or translation plugins will be part of the collection? For assurance: just fork? Can we add each other as collaborators? move the repos into the albertlauncher project? Other projects are able to manage plugins and compatibility limits, what are they doing different? Of course I also agree with you guys, just trying to think out of the box and also im not a developer 🙃 |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of having plugins not downloaded by default but be available to install from within albert. That sounds like it would provide the most benefit to maintainers and users in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
f*** *** github. just just wrote like about an A4 page and gh blew it up because of a freaking details html bug. will make it short now sorry.
docs should be in app in the end
a plugin is like 15kb. i personally dont care and it is totally worth it not to have to search the internet for plugins.
zero trust needed in a central upstream repo because of peer reviews.
solution is a central repo. no dupes. i do my best do notify people if they are working on the same thing. also I keep an eye on the default triggers.
yes fork. no keep it in your account and send a pr on cool things. gnah wrote so much on colaborators. but in the end i dont know much about github features and PRs work just fine.
short: they have either manpower or suck. albert has totally no manpower. i dont want it to suck. so we need lean management. no subs is a lean decision.
not really. but not seldomly people fixed things in my plugins or I fixed things in their plugins. there will be an update soon where I(we) have to update the iid from 0.5 to 0.6. I can annoy all maintainers or just write a sed script.
nice :D looking forward ship your ideas |
Beta Was this translation helpful? Give feedback.
-
btw what exactly do mean by compatibility limits? if you refer to backward compatibility well… the api is still developing. i know there will be a lot of changes. like the class hierarchy just got exposed to python. this took a lot of investigation. sometimes i find better techiques. sometimes i have better ideas. sometimes I just released bullshit before. (👋 albert::GlobalQueryHanlder::applyMruScores). This backward compatibility intervals dont last long in beta phases (but well the last one (0.17) was about 4 years or so. okayish for betas. I rather had the other problem. people said albert dead, because the stable branch was … just stable. 0.18 wont last long because of this applyMru dumb stuff. but it wont break anything I dont have under control. nobody will notice the transition to 0.19… unlike 0.18 :D |
Beta Was this translation helpful? Give feedback.
-
Thanks for the heads up. I'll start migrating to the new API and possibly make some PRs next week. Are you still keeping the https://github.com/albertlauncher/awesome-albert repo? I feel like it's a good place for plugins that for one reason or another are not merged to the |
Beta Was this translation helpful? Give feedback.
-
In the best case i can remove it because all of them are maintained and shipped. Even if not there will be probably not many plugins left. If you check this search most people dont care/know this repo anyway. |
Beta Was this translation helpful? Give feedback.
-
Hi @Pete-Hamlin @DenverCoder1 @bergercookie @Bierchermuesli you have posted a lot of cool plugins on awesome-albert. Finally I managed to get 0.18 published (took like three years or so?:D). For users i'd like to get them upstream such that even average users can benefit. I'd appreciate if you could send them as a PR into the https://github.com/albertlauncher/python repo. Thank you for your time! Obviously because I strive to get a somewhat more sophisticated maintenance of the plugins I want to ask if you like to be the maintainers of your plugins. (if so add your github name in the md_maintainers field)
Regards
Beta Was this translation helpful? Give feedback.
All reactions