Plugin manager for EG

[jonib]

Interesting development here.

filter out anything that is not a zip, rar, or __init__.py

How do you (Or do you) detect multi file plugins like my XBMC2 plugin? That needs both __init__.py and xbmcclient.py.

jonib

[kgschlosser]

Interesting development here.

filter out anything that is not a zip, rar, or __init__.py

How do you (Or do you) detect multi file plugins like my XBMC2 plugin? That needs both __init__.py and xbmcclient.py.

jonib

well i had to strap on my geek cap nice and tight for this one



well multi file plugins would have been zipped or rared. so what i did was i created a program outside of eg.

it created an eg class and added the eg class to sys.modules. and then i iterated through the list of attachments. and if one was a rar or a zip or a py it looked at the topic for the forum post and set that as a "temporary" plugin name downloaded the file from the server if it was a zip or rar decompressed it into a temp folder and if __init__.py just plopped it into a temp folder looked at the temp folder to make sure it had __init__.py and then it created a "plugin" instance that set the eg,RegisterPlugin to point to a method in that plugin instance so the data could be recorded and this also verified that it was in fact a plugin and not some other code. then ran exec on the __init__ i know not the smartest thing to do but glad we have a bunch of nice folks in here no malicious code . now by no means is this perfect because if someone didn't follow plugin writing guidelines and had all their imports before the RegisterPlugin if there was an import pointing to something else in eg then it would fail. but in this case i had it keep the decompressed folder and also print an error to a file so it can be manually gone through. at the end of the RegisterPlugin i had it throw an exception. if that exception never took place. i know that RegisterPlugin was never called so there for not a plugin.but if it is thrown i now have all the information from the RegisterPlugin save for one the GUID if they didn't provide one. and in that case i then have it read the whole __init__.py looking for a subclass of eg.PluginBase eg.PluginClass eg.RawReceiverPlugin. if i found one of the 3 grab the name and put that name in the GUID field.

then create a new zip file with the filename formatted like so SOMEPLUGIN.1.0.3.egplugin the numbers being the version of the plugin. along with generating the info.py file. and put the newly created .egplugin into a separate folder then delete the temp folder. if it's a duplicate (which there are) then add Duplicate-NUMBER to the filename. now with the duplicates i did not have it actually compare the code files. there is going to have to be some human interaction with this and the plugins have to be filtered and checked. but at least now they are all in one place and converted to the new .egplugin i feel that this was a pretty accurate method for sorting and checking if the file is a plugin or not.. any errors during the process it didn't remove the tmp folder and the temp folder is named from the topic of the forum post so it can be identified and sorted through. there are about 120 of those. and there was also some kind of issue with the server timing out with specific forum posts when downloading the file. which is odd because if i copy and paste the url right from the error printed it downloads from my browser just fine. there are only 40 of those so i wasn't going to tear my hair out on that one. i can just manually go and get them it made a separate log with those entries.

really was pretty simple.

[jonib]

well multi file plugins would have been zipped or rared. so what i did was i created a program outside of eg.

Well I don't follow your rules, mine was separate. But apparently I have removed the files from the plugin thread, as the other file (Kodi support file) is included in EventGhost and hasn't changed in years.

now by no means is this perfect because if someone didn't follow plugin writing guidelines and had all their imports before the RegisterPlugin if there was an import pointing to something else in eg then it would fail. but in this case i had it keep the decompressed folder and also print an error to a file so it can be manually gone through.

Looks like I missed that guideline, I have most imports before the eg.RegisterPlugin part.

jonib

[kgschlosser]

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.

[kgschlosser]

well multi file plugins would have been zipped or rared. so what i did was i created a program outside of eg.

Well I don't follow your rules, mine was separate. But apparently I have removed the files from the plugin thread, as the other file (Kodi support file) is included in EventGhost and hasn't changed in years.

now by no means is this perfect because if someone didn't follow plugin writing guidelines and had all their imports before the RegisterPlugin if there was an import pointing to something else in eg then it would fail. but in this case i had it keep the decompressed folder and also print an error to a file so it can be manually gone through.

Looks like I missed that guideline, I have most imports before the eg.RegisterPlugin part.

jonib

tisk tisk tisk...


you are supposed to import eg

then call eg.RegisterPlugin

then do all the rest of your imports.

this is because when eg loads the plugin file it will pop an exception when the eg.RegisterPligin is called halting the load of the plugin. this way a module doesn't get loaded into memory when it doesn't need to be for 1. but for 2 speed on startup. it doesn't have to load the additional modules unless the plugin is actually in the tree

[jonib]

tisk tisk tisk...

Don't you tisk at me tisk at Kirs as I learned the bad stuff from his plugin here.

jonib

[Sem;colon]

Well, but if you import files you ship with the plugin, you need to do it before the eg.RegisterPlugin, as it will not work otherwise.

[kgschlosser]

well then that's fine. that will work properly. just not anything like

import eg.utils

or any other eg import before the eg.register plugin beside import eg

but at any rate. i wrote a script to go through all the .egplugin files and verify if something is actually a duplicate or not. or if it's just a duplicate because there was a change and the version was not changed

and there were 209 duplicates only 20 of which were actual duplicates. and have been removed. i am assuming there are bug fixes that have been made and the version number was not changed on the remaining 191.

so at this point i am going to have to have to go back through the plugins and iterate each and every duplicate and compare them against each other and open a dialog showing where the difference is and a human is going to have to look at it to see which is what and how to deal with it. there is no other way at this point... but having it do the leg work and open up a dialog showing the changes is going to make the process a hell of a lot faster. and i am thinking that adding an aditional .1 to the end of the version for each might be the solution. not sure...

[kgschlosser]

and as far as the imports are concerned.. you are correct with that. and i truly dislike the way EG handles plugins. it loads a horrible about of information at startup when it's only needed by 1 dialog. that can be changed if the plugins were stored in egplugin files because the file can be opened and just the info.py be looked at. i think that all the parameters that are contained within the eg.RegisterPlugin should be in the info.py and only the plugins that are installed should be in folders. and upon removal the folder should be deleted so when scanning the plugins for that 1 dialog the plugin actually never gets loaded. only the info.py. and the plugins should only be scanned when that 1 dialog gets opened and when it gets closed all the information it loaded needs to be unloaded

this makes much more sense to me. and is a much more efficient way of doing things and can speed up the load time of EG up to a couple of seconds depending on the computer

[topix]

What about licensing issues?

I would say, if someone post his plugin here, it would be ok to list it in the plugin manager.

I think it would be a different situation if the plugin files were left in their current location and the URL to that file was saved in the database

That's why i already have attribute donload_url in the list/database i currently use for the manager.

but there are issues with that due to different packaging of the plugin files.

A solution could be to check if the download links to egplugin-file, if not show that link with the information that the plugin needs to be downloaded and installed manually.

[kgschlosser]

any kind of legal implications end if the plugin is obtained from this server, the reason being is that EventGhost is a not for profit outfit. and storing something on this server for personal gain without the express permissions of the eventghost organization is grounds for a lawsuit in and of it's self.. the worst thing that could ever happen is someone says "hey get my plugin out of the plugin repository". and at that moment in time we remove the plugin but also remove anything about that plugin from the forum.

problem solved.. what is stored on eventghost servers is the property of the eventghost organization.. plain and simple. now on the other hand if you put a link to a different site where it is located. then that is your business. but you also have to obtain permission to post this link. and also get permission to charge for something that uses free software in order to function. i feel that one of the things that should be done is some kind of a "rule" or disclaimer stating that any plugins that an author wants to make for eventghost has be be GNU and free. period.

and in all honesty. i will guarantee that not a single plugin that states it is copyrighted really is.. and the header in the code file stating that it is really means nothing. the process to actually get something copyrighted is obnoxious. and for some crazy reason people think that putting that little c after something means it is copyrighted... nope.. it doesn't it's just another character in the ascii table unless you have actual copyright documentation stating what the plugin is what it does how it is used and so on and so forth... and i think there would also need to be permission from the "core" program organization to allow said plugin to use it.. and without that permission no copyright.

i have not done any research on software copyrighting but this seems like how it would be done. and from what little bit of poking around i did. i found these 2 things below..

this is right from the Copyright website

Code: Select all

How do I copyright a name, title, slogan, or logo?
Copyright does not protect names, titles, slogans, or short phrases. In some cases, these things may be protected as trademarks. Contact the U.S. Patent & Trademark Office, [email protected] or see Circular 34, for further information. However, copyright protection may be available for logo artwork that contains sufficient authorship. In some circumstances, an artistic logo may also be protected as a trademark. 

so anyone that has put a little c after their name it means nothing



this should put anything about any legalities at ease this is right from the gnu website 2nd paragraph is how EventGhost operates

Code: Select all

If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in? (#GPLAndPlugins)

    It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

    If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way.

    If the program dynamically links plug-ins, but the communication between them is limited to invoking the ÔÇÿmainÔÇÖ function of the plug-in with some options and waiting for it to return, that is a borderline case.

there is no legal implications that can take place from plugin author to EventGhost. now on the other hand... it can defiantly go the other way. and any plugin author that has any stated copyright other then a GNU should change this and remove anything other then the GNU. because technically that is infringement.

[jonib]

the process to actually get something copyrighted is obnoxious. and for some crazy reason people think that putting that little c after something means it is copyrighted... nope.. it doesn't it's just another character in the ascii table unless you have actual copyright documentation stating what the plugin is what it does how it is used and so on and so forth... and i think there would also need to be permission from the "core" program organization to allow said plugin to use it.. and without that permission no copyright.

You get the copyright for what you make automatically, you don't need to apply to get it, only if you want/need extra protection. Copyrighting Your Software ÔÇö Why Bother?

jonib

[kgschlosser]

now onto a different topic since the legal junk should be taken care of..


as far as the plugins go... there should be some kind of a standard put into place as far as things like docstrings and where to obtain help what the header needs to be..

proper explanation of how to use the internationalism. because i am one that failed at it as are so many other plugins... you can name your "Text" class anything you want. EG does not look at the module level for "Text" it looks at the subclass eg.PluginClass... and this is what is supposed to be used not eg.PluginBase. but it sets an attribute of text to the PluginClass of None so when you do text=whatever in the plugin class it overrides the None and eg will do a translation at that point. also what it does is when adding actions if the action class name is defined in the text class and is also a class it will add the text attribute as that named class inside of text to the action... so there is no need to define text in the action class as it has already done this and if you do define it. it will cause issues with setting the language of eg if that plugin is located in the plugins folder. it is kind of crazy how that is set up and took me a while to figure it out. as the documentation for this provides choices... and there should be only one way.. but also if you do define text in an action if will look in there for the name and description and if you put the name and description in the action it will not use those...

there should be a template of sorts or really specific guidelines for how plugins should be authored

and this should be something that is POW right in your face easy to find and follow...

I also think that maybe there should be guidelines as to multiple files. like putting actions into separate files one and the name of the file needs to be the same as the name of the action.. this makes for better code organization.. and putting the code that pertains to that action in that action file.. Unless more then one action uses the same code then it should be put into the Plugin class.

and making use of __init__(), __start__(), __stop__(), __close__(), an also the little known OnDelete() even if you just pass them

the OnDelete method should also contain a del(Config) if there is a Config(eg.persistantData) used this will clean out the settings from the config.py file instead of leaving them orphaned in there.. this has cause me issues when upgrading a plugin and an attribute was added to the default Config in the plugin file. because it would not set that new attribute resulting in a traceback because the Config was loaded from the config.py and not the default in the plugin file

and showing proper thread termination so EG closes all nice nice.

thing like this..

there is so much that EG actually does that is not documented and to be honest with you I have not even seen used

[kgschlosser]

the process to actually get something copyrighted is obnoxious. and for some crazy reason people think that putting that little c after something means it is copyrighted... nope.. it doesn't it's just another character in the ascii table unless you have actual copyright documentation stating what the plugin is what it does how it is used and so on and so forth... and i think there would also need to be permission from the "core" program organization to allow said plugin to use it.. and without that permission no copyright.

You get the copyright for what you make automatically, you don't need to apply to get it, only if you want/need extra protection. Copyrighting Your Software ÔÇö Why Bother?

jonib

have you read the whole article???

is says that you do have to have it just don't bother until you want to sue someone. but at that point the argument can be made about the fact there wasn't one and that they just obtained the proper license. the argument is called "innocent infringer" because there was not proper notice proper being formatted correctly as well as displayed. and the use of a copyright for a "plugin" for GNU GPL licensed software pretty much means nothing. because the GNU GPL overrides it (in the case of EventGost)

and where to put that little c. after your name is not correct in fact it should be posted

┬® Copyright 2001 John P. Doe. All Rights Reserved.

not
John P. Doe ┬® 2001
or
John P. Doe 2001 ┬®

putting the ┬® after your name means your name is copyrighted and you can't copyright a name

and also using a "C" or a "c" doesn't work either

[kgschlosser]

and i forgot to mention. on download able items it should be posted before the link to download it.