Plugin manager for EG

[pearbear]

what i can do is a search for the GNU-GPL in the header of a plugin anf if it is not found omit it from the list unless we were able to obtain written consent from the author. but from this step forward i do believe the traditional EG header is a mandate in a plugin and upon adding it to the repo if it is not there then it will kick it back. i think that the GNU actually should be located in a separate file called license.txt and a balloon statement for all files located within the contents of the .egtree file are apart of the GNU-GPLthis should be added either as a file or a comment in the compression.

Note that it says:

This means you must license the plug-in under the GPL or a GPL-compatible free software license

so the GPL license is not required. For example, I like to use the MIT license on my code because it seems to be the more permissive license but that license is GPL-compatible so I could use that license in an EventGhost plugin without being in violation of EventGhost's license.

are we going to provide all versions of a plugin available??? or just the most up to date.. the reason why i ask this is because of the possibility of a new version of a plugin not being compatible with an older version of EG.

I think it would be really nice to have all versions in the database, default to installing the most recent but allow the user to install or roll back/forwards to any available version of the plugin. Sometimes bugs are introduced in the new version and it's very useful to be able to roll back to check if using an older version will make an issue go away. As you said, future EG versions may require changes in plugins that will break backwards compatibility with previous EG versions. If the user has other unmaintained plugins installed that aren't compatible with the new EG version then they may not be able to upgrade their EG and thus can't use the new plugin versions that aren't backwards compatible.

On a related note, there is a good discussion about adding version compatibility metadata to the plugins here: https://github.com/EventGhost/EventGhost/issues/89, which would be a very useful feature for the Plugin Manager.

[kgschlosser]

well maybe we should address how the metadata should be laid out and i can add that now or we can wait. doesn't matter to me.

[Sem;colon]

so the GPL license is not required. For example, I like to use the MIT license on my code because it seems to be the more permissive license but that license is GPL-compatible so I could use that license in an EventGhost plugin without being in violation of EventGhost's license.

So, if that's how it works, I'd license the __init__.py as MIT and all the other files I ship under a commercial software license (it's a web interface for EG, it has many files) and everyone is happy, right?

On a related note, there is a good discussion about adding version compatibility metadata to the plugins here: https://github.com/EventGhost/EventGhost/issues/89, which would be a very useful feature for the Plugin Manager.

+1

[topix]

disclaimer.png (5.95 KiB) Viewed 6087 times

Would this be ok as part of the legal issues?

[eirik226]

disclaimer.png

Would this be ok as part of the legal issues?

Do you really need to have it in the plugin itself like a box? Isn't it enough to just write it when you install EG, or something like that? I have no clue, just asking.

[jonib]

I think having a disclaimer the first time you install any plugin is best, preferably it can be hidden after.

jonib

[kgschlosser]

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS, COPYRIGHT HOLDERS, EVENTGHOST.COM, EVENTGHOST.ORG, EVENTGHOST.NET,
GITHUB.COM/EVENTGHOST OR ANY OF THE PAST/PRESENT AUTHORS AND CONTRIBUTIORS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH
THE SOFTWARE OR ANY OF THE PLUGINS OBTAINED FROM INSIDE THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

THE SOFTWARE AND ANY OF THE PLUGINS AVAILABLE FROM INSIDE OF THE SOFTWARE
ARE DISTRIBUTED UNDER THE EVENTGHOST GNU-GPL V2


gotta cover everyone including the people that don't even do anything with the project anymore

[kgschlosser]

there should be a TOS help menu item or a button in the about for a TOS. for EventGhost it's self. as well as for all of the plugins. with links pointing to the different subsections on the GNU website and any contact e-mails that need to be given if there is some kind of a dispute about the distribution of a plugin

it's some pretty typical crap. and also if eventghost is going to send any data for downloading plugins. like the version number of the program. this needs to be stated that electronic software version information is going to be sent to another server in order to compile a list of plugins that will function with the currently installed version of EventGost

and you can go into explicit detail about what exactly gets sent. but even if nothing gets sent. there still needs to be a notification each and every single time the thing is going to connect to obtain that list of plugins the user has to click OK on. now you can provide that little checkbox "don't show this again" and that is cool to do, because they are knowingly dismissing that message and by doing so it gives EG the authorization to send whatever data it needs as well as make the connection..

[dequi]

ok so this is what i have thus far...

i have sorted the connection issue ones.. and the totals thus far are 290 unique plugins...

there are different versions of each plugin totaling somewhere around 836 .egplugin files.

If possible, I'd love to get a copy of your list and the .egplugin files to parse, search and browse...well basically - have my way with it

[kgschlosser]

I can arrange that.

they really need a going through. and I am guilty of this as well. but if it is a minor bug fix i wouldn't always roll the version number. and I am sure quite a few of the duplicates are from this exact thing. I would have to make the thing so it would open up the duplicate and load the files and see if in fact they are different or not. this should shrink the number of duplicates

I also want to get a running total of the number of plugins. and not a total of the number of egplugin files. because there could be 100 versions of one plugin.

[dequi]

I can arrange that.

Well, I could keep on waiting or... start on my own plugin list.

I also want to get a running total of the number of plugins. and not a total of the number of egplugin files. because there could be 100 versions of one plugin.

I'm currently up to 323 unique plugin names, sorted by version. and yes there are a bunch with the same version while different from each other.
At this point going trough to manually identify versions that my parser missed (I'm up to J), and identify the bundled ones (I'm up to C).

https://github.com/dequi/EventGhostPluginDB

It should be noted that plugins that were uploaded to the forum as an archive are complete, the others are just the .py file that contains the eg.RegisterPlugin() function and could be missing essential files to be run but that is a problem to solve later.

[dequi]

Last tally with all CORE and BUNDLED plugins identified is 360.

[kgschlosser]

Well, I could keep on waiting or... start on my own plugin list.

well Hell you haven't even asked for them... and you have been MIA for a bit...

It should be noted that plugins that were uploaded to the forum as an archive are complete, the others are just the .py file that contains the eg.RegisterPlugin() function and could be missing essential files to be run but that is a problem to solve later.

HA! I already accounted for this. as well as ran all of the conversions and also check for file uniqueness. I don't recall how many actual plugins there are... but there is a difference between number of plugins and number of plugins/versions. i think the 300+ number is for all of the various plugins/versions and not plugins in general.

I also had it break open all compressed archives and test the files as well.. and repackage everything into the egplugin format.

The only thing I would like to do with it is create a changelog of sorts to package with the different plugin versions. and I am very guilty of this. and making a minor bug fix and not increment the version... Tho it doesn't really matter what is in the info.py except for the simple fact it will be displayed when loaded.. tho it does not have to be the correct version number.. so i could set up a comparison between files and record the differences between the 2 and create a "changelog.txt" file and add the changed code to that. and add an additional version identifier onto the end of the existing version.. so version 1.1 would become 1.1.1 but only in the info.py file in the egplugin file. not in the actual plugin.. this way they can be separated until someone has the time to go through them and see what is what. but the changelog is also a means to identify which order the versions need to be incremented in..

so if one version has "hello" and "goodbye" in it and another does not. but there is also a 3rd file that just has "hello" then it would be 1.1, 1.1.1 (has hello), 1.1.2 (has hello and goodbye) because of this we can help along the sorting process But i can also parse the dates attached to the posts. to further help.


sorry you did the work.. you just posted yesterday at 2PM or so. and haven't heard anything from ya for a month. and my messages still say 0. you never asked... and i wasn't going to dump 360 plugins into the forum as a zip. LOL

[dequi]

well Hell you haven't even asked for them... and you have been MIA for a bit...

If possible, I'd love to get a copy of your list and the .egplugin files to parse, search and browse...well basically - have my way with it

So this wasn't me asking? I'll pm you my email. Happy to review your work . It doesn't really matter I'm doing the same thing all over, If we end up at the same place we know we both did it right I see it as learning experience.

Yes I have been MIA for a bit... I try to spend some time where I can... It won't improve in the short future.

The only thing I would like to do with it is create a changelog of sorts to package with the different plugin versions.

Was thinking the same thing to add a CHANGELOG.md to all plugins.

[pearbear]

Was thinking the same thing to add a CHANGELOG.md to all plugins.

With plugins that are using publicly available version control like a Git repository, such as the stock EventGhost plugins, the commit history is the best changelog. I think having to maintain a separate (and likely far inferior) changelog is a pointless waste of effort in those cases and it's better to just have a link to the repository.