[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] gc client extension loading ordering

The first thing that pops into my head is that trying to figure out the order becomes a headache. Pure alphabetical has the benefit of being able to be seen with "ls -l".

But your argument about it being bad python to start a package name with _ is really solid too. And I think it outweighs the above point.

One of my biggest concerns with the extensions is that I want the barrier of entry to writing one to be as small as possible. But I think we can still maintain that by making the ordering optional.

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.

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.

I dig it.

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.


-- James Slagle

Pulp-list mailing list
Pulp-list redhat com

Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]