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.
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
