[Pulp-list] gc client extension loading ordering

[James Slagle]

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
> >Pulp-list at redhat.com
> >https://www.redhat.com/mailman/listinfo/pulp-list
> 
> 
> -- 
> Jay Dobies
> Freenode: jdob @ #pulp
> http://pulpproject.org | http://blog.pulpproject.org
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
--
-- James Slagle
--