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
