On Fri, Feb 24, 2012 at 10:49:17AM -0500, Jay Dobies wrote: > So all Pulp built in extensions have a priority of 1. The ordering > is done in the module like you suggest, but it's entirely optional. > If it's omitted, it defaults to, say, 5.
Agreed, I like the optional part. But maybe make built ins not be 1, but something higher. We allow for a bit more flexibility if anything ever needs to get loaded before the builtins, speaking from a hypothetical standpoint (i can't think of a valid reason). There's always an infinite amount of numbers between any 2 integers though, so perhaps it doesn't matter :). > That way we have the power to order if we need to without adding > another step to the extension creation process. I really like > stuffing it in the __init__.py since it's not another file we have > to tell them to create; they have to create that anyway. And you're > right, it'll fit right in after loading but before calling init. > > If displaying the ordering really becomes an issue (I don't think it > will), we can always add a flag to the client that won't actually > start the UI but rather just print out the module ordering as > determined by the loader. +1. > > On 02/24/2012 10:33 AM, James Slagle wrote: > >I wanted to explain the idea I proposed during the deep dive about ordering > >the gc client extension loading. Instead of relying on alphabetical order, > >each extension model could define a module level variable that represented > >it's loading priority as a number. Call it PRIORITY if you will. > > > >Extensions could be imported, but before their init methods are called, they > >could be sorted based on the module.PRIORITY variable. > > > >Extensions with the same PRIORITY, meaning they don't depend on anything else > >with the same PRIORITY, could then be loaded alphabetically if we have to > >enforce an order. > > > >This isn't all that different from the way it's being done now, in that it > >still uses an arbitrary system for the load order. We're still not expressly > >listing dependencies or anything. > > > >Alphabetical loading by module name does have some advantages over this > >proposal, one of which is that you could easily see the loading order just by > >looking at a directory of files. But, I think you're still going to get into > >situations where you have to start prepending lots of a's and z's to get the > >order you want. For example, if there's a new builtin pulp extension that > >needs to depend on _pulp_repo.py, we've basically made it such that the new > >extension needs to start with _pulp_[s-z].*, so that it gets loaded in the > >correct order. > > > >Using a module level variable would also make it so that we don't have to > >prepend _ to the pulp builtin extensions. I really feel we should try and > >follow PEP8 as much as possible. While having _'s at all in module names > >is debated, leading _'s almost always indicates a C compiled .so > >python module. > > > >Thoughts? > > > >-- > >-- James Slagle > >-- > > > >_______________________________________________ > >Pulp-list mailing list > >[email protected] > >https://www.redhat.com/mailman/listinfo/pulp-list > > > -- > Jay Dobies > Freenode: jdob @ #pulp > http://pulpproject.org | http://blog.pulpproject.org > > _______________________________________________ > Pulp-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-list -- -- James Slagle -- _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
