From: Doug B. <dou...@gm...> - 2009-10-25 21:46:39
|
On Sun, Oct 25, 2009 at 4:59 PM, Doug Blank <dou...@gm...> wrote: > 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. > >> 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. I speculated: > 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... Nope... apparently you can't put the registration code in the same file as the code for the plugin for the simple reason that you can't "import filename.gpr". Benny, if you change the API to search for filename_gpr.py then we could combine registration and definitions in a file, if we wanted to. Currently, I believe it is impossible. -Doug |