From: Benny M. <ben...@gm...> - 2009-10-26 09:27:05
|
2009/10/25 Doug Blank <dou...@gm...>: > On Sun, Oct 25, 2009 at 4:01 PM, Brian Matherly > <br...@gr...> wrote: >> Benny, >> >> Two comments about the new gpr.py files in the plugin directories: >> >> 1) All the .gpr.py files I looked in are completely missing the mandatory license statement at the top. This violates the project policy for source license identification. > > That's a good point... I'm noticing some other newer files that were > missing the license, at least initially. It probably should be the > case that the initial version of any source code has the license > attached to it. Otherwise we end up in the situation that we have some > code accessible (through SVN revisions) that don't have a license in > the file. This was on purpose. My reasoning was the following. I originally intended to use xml files, as the GEPS proposal shows. However, Richard Taylor convinced me to go with python files instead, it simplifies things a lot. I nevertheless still consider the .gpr.py files as text files with the definition of how a plugin is defined. We could in the pluginregister allow for .gpr.xml files, and obtain the exact same result. Just as our keys.ini file with settings has no copyright statement, the .gpr.py files have none. Should I add it nevertheless? Personally I don't think anything copyrightable is in those files, but I don't mind adding the statement for clarity sake. Ok, I'll just add it. > >> 2) I know Doug asked this previously, but I don't remember seeing a satisfactory response: Why does the plugin registration code have to be in the .gpr.py file? Why can't it be at the bottom of each respective plugin source file like it used to? What does the .grp.py file gain us? Sorry if I missed your previous response. > > I think I can answer this in two words: speed and dependencies. By > separating the registration from the actual code, Python doesn't have > to parse/run the entire file. This might not sound like a big thing, > but there are over 75k lines of code that now do not have to be parsed > (or executed) on startup (I counted). Even code that only defines > classes still must execute them. > > But perhaps more importantly, all of the imports done by all of the > plugins can be delayed until (or if) the plugin is actually used. This > is a huge list of dependencies, probably numbering in the hundreds (I > tried to count, this is a little harder to get an exact, recursive > count). All of those imports (and the items they in turn import) can > be delayed. This is a huge win if you are just running a report from > the command-line. It also makes a very nice, modular system from a > webserver. > > However, one can sill use a single file to define and register the > plugin (I think). It just has to end in ".gpr.py". I'm testing this > now in looking at 3rd party plugins... Yes, The main reason to do it so is seen in the following output of the same command in 3.1 and trunk: 3.1 output: ======== $ time python src/gramps.py -l location: /usr/lib/xulrunner-1.9.1.3/libxpcom.so before 3 List of known family trees in your database path /home/benny/.gramps/grampsdb/4a1cf6b8 , with name 1.0 xml /home/benny/.gramps/grampsdb/4a1cffba , with name 2.0 xml /home/benny/.gramps/grampsdb/4a1168df , with name 3.0 fam tree /home/benny/.gramps/grampsdb/49aba165 , with name Family Tree 1 /home/benny/.gramps/grampsdb/4a1d08d3 , with name bug2847 /home/benny/.gramps/grampsdb/4a13d74e , with name import priv test /home/benny/.gramps/grampsdb/4a1f84f3 , with name noteref /home/benny/.gramps/grampsdb/4a1d04ca , with name test /home/benny/.gramps/grampsdb/49b7cf48 , with name trunk example real 0m2.647s user 0m1.616s sys 0m0.392s trunk output ========= $ time python src/gramps.py -l List of known family trees in your database path /home/benny/.gramps/grampsdb/4a1cf6b8 , with name 1.0 xml /home/benny/.gramps/grampsdb/4a1cffba , with name 2.0 xml /home/benny/.gramps/grampsdb/4a1168df , with name 3.0 fam tree /home/benny/.gramps/grampsdb/49aba165 , with name Family Tree 1 /home/benny/.gramps/grampsdb/4a1d08d3 , with name bug2847 /home/benny/.gramps/grampsdb/4a13d74e , with name import priv test /home/benny/.gramps/grampsdb/4a1f84f3 , with name noteref /home/benny/.gramps/grampsdb/4a1d04ca , with name test /home/benny/.gramps/grampsdb/49b7cf48 , with name trunk example real 0m1.092s user 0m0.732s sys 0m0.172s Conclusion ======== More than 50% faster for this CLI action, but more importantly for me, in trunk we no longer see on the output for this CLI action: location: /usr/lib/xulrunner-1.9.1.3/libxpcom.so before 3 Which proves that due to loading the plugins, we load pygtk/gtk.builder and all it's dependencies. Loading the plugins at start means a huge amount of other libraries are loaded, on my box, for 1.5seconds of running time. This 1.5 sec is no problem for GUI, but for CLI, or for a webserver that uses gramps to produce report output, it is a nice thing to have. Now take into account I want to make the dataviews plugins, which was my argumentation to do this change now. Those are not loaded at the moment when CLI is done, but if they become plugins, in the old systhem they would be loaded, and the views are many lines of code again Extra points I considered to choose this method: * it is a common pattern to do plugins (see eg http://live.gnome.org/Gedit/PythonPluginHowTo , so a pluginname.gedit-plugin file with text, and a compiled file) * security, going to xml allows security before importing a plugin. Using python now this is not the case, but we can do some safe checks on the gpr.py file, and the actual plugin is only loaded if the user runs the plugin. * versioning, a plugin aurthor can ship a tar/zip with one gpr.py file and several plugins for different versions of GRAMPS. This is obviously possible in the old system by raising an ImportError after check of the gramps version, but then the plugin shows up in the plugin status with fail. With gpr.py the user sees no problems passing by, it can be made to just work. * versioning with upgrade, a user upgrades gramps, but the old plugins are still present, and now fail because present plugins have no versioning checks, this can be avoided in the future. ... Benny >> Thanks, >> >> ~Brian >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |