Plugin load order

[coderanger@…]

As more plugins are made, there are starting to be dependency issues. As of now this is mostly limited to WebAdmin sub-plugins, but there will be more as time goes on. My current issue is a plugin being loaded before WebAdmin, and dying when it can't find the webadmin module. I have tried putting the WebAdmin egg in both site-package and the project's environment. Below is an excerpt from the log.

01:17:56 Trac[loader] DEBUG: Loading plugin ticketdelete from /var/www/coderanger/tracs/tracdev/plugins/TicketDelete-0.1-py2.4.egg
01:17:56 Trac[loader] ERROR: Component module ticketdelete not found
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/loader.py", line 42, in load_module
    module = __import__(name)
  File "build/bdist.linux-i686/egg/ticketdelete/__init__.py", line 1, in ?
    from _dbus import *
  File "build/bdist.linux-i686/egg/ticketdelete/web_ui.py", line 7, in ?
ImportError: No module named webadmin.web_ui
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.logging from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.ticket from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.basics from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.perm from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.web_ui from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin webadmin.plugin from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.1dev_r2765-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin traccas from /var/www/coderanger/tracs/tracdev/plugins/TracCAS-0.1-py2.4.egg
01:17:56 Trac[loader] DEBUG: Loading plugin hackinstall from /home/coderanger/trac/hacks/hackinstallplugin/0.9

[Alec Thomas]

The setuptools dependency listings could presumably be used for this:

setup(name='TracHacks',
      version='0.1',
      packages=['trachacks'],
      entry_points={'trac.plugins': 'TracHacks = trachacks'},
      install_requires=['TracXMLRPC', 'TracAccountManager'],
      )

Perhaps Trac could inspect dependencies, or hook the require() functionality somehow (not sure this is actually possible from looking at the setuptools documentation).

[coderanger]

It seems that a possible answer is to add this before the webadmin import:

import pkg_resources
pkg_resources.require('TracWebAdmin')

I have tried this on the offending plugin and will see if the problem returns. I don't see this as a good fix, but it may be the best option until something more detailed can be worked into trac.loader.

[anonymous]

A quick hack is to rename the .egg files so that they are listed alphabetically in the correct order. At least this worked for us

alex dot corcoles at kroopier dot com

[pacopablo]

Patch for plugin dependency support

[pacopablo]

Just attached the patch based on cmlenz's stuff to fix the dependency issues. So far it's working for me. The key seems to be the fact that the default working_set needs to be used.

Now, plugin can set install_requires in their setup.py and it will make sure that those that it requires are loaded first.

[Christopher Lenz]

Patch applied in [3097]. Thanks!

[ximon.eighteen@…]

Hi, just wanted to record an extra complicated case, I'm not going to reopen the ticket because I have at least two work arounds.

I have some plugins that provide Web Admin interfaces but of course they don't *need* the web admin interface to be installed in order to work, the config can be manually edited in the config file.

So, I surrounded the import of IAdminPageProvider with a try except block and if it is missing define the missing interface manually to keep the Python interpreter happy, even though the web admin code will never be invoked (which I don't care about).

However, in setup.py I don't want to mark Web Admin as *required* any more because it isn't *required*. Instead I list it in extras_require. Everything seems to be fine, except that now the load order bug is back.

The two work arounds I referred to are the naming hack (name the plugin after webadmin in the alphabet to manually affect the load order) or by splitting out the web admin code into yet another plugin. So long as communication between the non-web admin plugin and the web admin plugin happens via a consistent API there shouldn't be a problem, but it's a bit messy.

[ximon.eighteen@…]

Hmmm, could the loader code be extended to handle 'extras_require'? I don't know anything about pkg_resources but looking ​here I see:

requires(self, extras=())

List of Requirements needed for this distro if extras are used

I can see the code is using as_requirement at present, would it help to use requires?

[ximon.eighteen@…]

Okay this gets weirder. My loader.py doesn't look like loader.py in ​revision 3097 even though ​this seems to say that 0.9.6 was tagged at revision 3510. When I investigate deeper I find that the revision of loader.py in 0.9.6 is 2724 which therefore doesn't have the fix that was made on the trunk in 3097. I find this odd since this ticket is marked closed fixed and version 0.9.3. What am I missing here?

[ximon.eighteen@…]

FYI applying patch ​3097 didn't fix my problem, and neither did a brief attempt to use dist.extras and dist.requires(). I guess I'll list this as a known problem in my plugin and name it higher than webadmin before distributing it, and see if 0.10 helps since the trunk loader.py is different than the one in 0.9.6.

[Christian Boos]

Replying to ximon.eighteen@int.greenpeace.org:

Okay this gets weirder. My loader.py doesn't look like loader.py in source:trunk/trac/loader.py@3097​ …

The issue was reported against version 0.9.3, but the fix happened on trunk, for milestone:0.10 (as this is the case for most bug reports/enhancement requests; only critical bug fixes go in 0.9.x stable).