Opened 16 years ago
Closed 15 years ago
#7869 closed defect (worksforme)
Plugins "creep" from one trac environment into the other
Reported by: | 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 , 16 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 by , 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 , 15 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
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 , 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.
follow-up: 7 comment:6 by , 15 years ago
Version: | 0.11.1 → 0.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??
comment:7 by , 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 , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
So, yes, there's nothing we can do about that…
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.