Edgewall Software
Modify

Opened 16 years ago

Closed 15 years ago

#7869 closed defect (worksforme)

Plugins "creep" from one trac environment into the other

Reported by: korn-tracbugs@… Owned by:
Priority: normal Milestone:
Component: general Version: 0.11.5
Severity: normal Keywords: plugin mixup
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Hi,

I use mod_python to serve multiple trac instances. The relevant parts of my apache config look like this:

        <Location />
                AuthPAM_Enabled on
                AuthPAM_Fallthrough on
                AuthType Basic
                AuthBasicAuthoritative off
                AuthName "Trac"
                AuthUserFile    /etc/apache2-trac/trac.pwd
                AuthGroupFile   /etc/apache2-trac/trac.group
                Require valid-user
        </Location>

        SetEnv MPLCONFIGDIR /var/tmp/trac

        Include tracs-enabled/

And then a typical trac instance would have a configuration like this:

<Location /misc>
        SetHandler mod_python
        PythonInterpreter main_interpreter
        PythonHandler trac.web.modpython_frontend
        PythonOption TracEnv /var/lib/trac/misc
        PythonOption TracUriRoot /misc
        AuthPAM_Enabled On
        AuthType Basic
        AuthBasicAuthoritative Off
        AuthName "Kitchen Sink trac"
        require valid-user
        satisfy all
# EGG_CACHE is different for all trac environments:
        SetEnv PYTHON_EGG_CACHE /var/tmp/trac/misc
</Location>

What I noticed is that if I start apache and then visit the admin/plugin page of trac A, everything is fine; but if I access anything from trac B that has a different set of plugins from A, and then revisit the admin/plugin page of A, it suddenly includes all plugins from trac B as well.

This leads to all sorts of trouble if those plugins modify data structures or APIs; for example, when the agilo scrum plugin creeps over in this way, it's no longer possible to view tickets in trac A ("ERROR: 'Ticket' object has no attribute 'time_changed'"). Since all plugins creep over, not just agilo scrum, I don't think this is a problem specific to that plugin.

It's entirely possible that I'm doing something stupid, but I couldn't figure out what.

Andras

Attachments (0)

Change History (8)

comment:1 by osimons, 16 years ago

Resolution: worksforme
Status: newclosed

Yes, seeing that they share the same interpreter they will both be available in shared memory without knowing where it originates - as explained in TracPlugins. However, a plugin that isn't enabled in one environment should not be active either - it should be skipped by Trac provided that the plugin is written correctly (encapsulating everything in a Component-based class).

So either a) The plugin is not done correctly, or b) you have enabled the plugin for more projects than you intended - typically by enabling it in a shared/global trac.ini.

Either way Trac itself behaves as expected, and if you need help with plugins or have particular questions, please use the trac-users MailingList to ask the community for advice.

comment:2 by anonymous, 16 years ago

void f()
{
  printf("hello world");
}

comment:3 by nkratz@…, 16 years ago

I am experiencing the same behaviour here. Also with an agilo configured and running in one trac instance and showing up in another where agilo.*=disabled. So I reckon it is agilo's fault.

comment:4 by hugosson@…, 15 years ago

Resolution: worksforme
Status: closedreopened

I am experiencing the same behaviour, I have defined different PYTHON_EGG_CACHE and when I add a .egg plugin to A/plugins this plugin appears also in project B. I am using trac 0.11.5, python 2.4 and httpd 2.2. (and mod_python).

What can I do?? I have tried with two differnet plugins, for example http://trac-hacks.org/wiki/SvnAuthzAdminPlugin][SvnAuthzAdminPlugin. I do not think it is an issue of the plugin.

comment:5 by Remy Blank, 15 years ago

Please read comment:1. You need to disable the plugins explicitly in trac.ini of the environments where you don't want them activated.

Another solution is to use separate web server instances for your different Trac instances, which will ensure that you run a separate Python interpreter for each instance. But this will also require running on separate ports.

comment:6 by hugosson@…, 15 years ago

Version: 0.11.10.11.5

Ok, thanks, but it will still appear in the plugin section on the web for all projects…. which means that anyone adding private plugins to private_trac_instance/plugins could just as well add them to python/site-packages??? Is there no other way (not the separate web server solution) to add private project specific plugins only for one trac instance??

in reply to:  6 comment:7 by Felix Schwarz <felix.schwarz@…>, 15 years ago

Replying to hugosson@…:

Ok, thanks, but it will still appear in the plugin section on the web for all projects…. which means that anyone adding private plugins to private_trac_instance/plugins could just as well add them to python/site-packages??? Is there no other way (not the separate web server solution) to add private project specific plugins only for one trac instance??

No, this is Python. As long as you have one process, you have a global package namespace. The only thing you can do is to avoid a multi-environment trac setup and use different processes to serve each of the environments.

comment:8 by Remy Blank, 15 years ago

Resolution: worksforme
Status: reopenedclosed

So, yes, there's nothing we can do about that…

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.