Opened 8 years ago

Closed 8 years ago

# doesn't appear in Trac's plugin list

Reported by: Owned by: Andrew Schulman robert_martin normal HtGroupEditorPlugin normal python2.4 0.11

### Description

I've installed HtGroupEditorPlugin version 2.0, but it doesn't show up in Trac's list of plugins (at admin/general/plugin).

I used 'python setup.py install --prefix=/EPA/usr' to install the plugin. The .egg file is installed in a global location (/EPA/usr/lib/python2.4/site-packages), in the same directory as Trac itself and some other plugins that Trac does find. The .egg is world-readable, and its path is included in easy-install.pth. Apache has PYTHONPATH set to include /EPA/usr/lib/python2.4/site-packages, and it does find other plugins in that location.

ConfigObj is installed in that same directory. I can start python and run 'import configobj' with no error.

Could this be a python 2.4 problem? Does HtGroupEditorPlugin work with Python 2.4? If that's not the issue, how can I determine what's going wrong?

Thanks, Andrew.

### comment:1 Changed 8 years ago by robert_martin

Status: new → assigned

Hi Andrew,

I don't know if it works with Python 2.4, it does with 2.6.

Can you please try having a look in the log file, and if nothing is seen try increasing the log level in the ini file. You should in effect give Trac a restart to make sure it picks up on the logging change be restarting Apache.

In the Admin/Plugins it should be listed as TracHtGroupEditorPlugin 2.0

Regards, Bob.

### comment:2 Changed 8 years ago by anonymous

I turned the log level up to DEBUG, restarted Apache, and reloaded the plugins page. The log doesn't show much, just the same bogus error message I always see about my SQLite installation being too old (which is false; I'm using SQLite 3.3.6 and PySQlite 1.1.7):

Jun 21 05:10:39 vaepaweb1 Trac[env] INFO: -------------------------------- environment startup [Trac 0.11.6] -----
---------------------------
Jun 21 05:10:39 vaepaweb1 Trac[sqlite_backend] WARNING: Support for SQLite v2 and PySqlite 1.0.x will be dropped i
n version 0.12, see http://trac.edgewall.org/wiki/PySqlite#UpgradingSQLitefrom2.xto3.x


Running python from the command line, I can run 'from htgroupeditor import *' without error. If you can think of any other simple tests that I can run to figure out where the problem is, I'll try them. If time permits I may also try using a debugger.

### comment:3 follow-up:  4 Changed 8 years ago by robert_martin

The only thing I can think of is permissions. By the sound of it you have TRAC_ADMIN rights to see the other plugins.

The method most likely to be causing the problem is the get_admin_panels in line 45. It might be worthwhile comparing it with the other plugins that show up OK. You could also try using the text strings directly without the translate function. It could be something in there. Replace

yield ('accounts', translation._('Accounts'), 'groups', translation._('Groups'))


with

yield ('accounts', 'Accounts', 'groups', 'Groups')


### comment:4 in reply to:  3 Changed 8 years ago by anonymous

The only thing I can think of is permissions. By the sound of it you have TRAC_ADMIN rights to see the other plugins.

Yes, I do have TRAC_ADMIN rights.

The method most likely to be causing the problem is the get_admin_panels in line 45. It might be worthwhile comparing it with the other plugins that show up OK. You could also try using the text strings directly without the translate function.

Thanks for the suggestions. I removed the translation functions, but it didn't help. I compared get_admin_panels() from other working plugins, and they look almost identical. I tried porting over the few differences I found, i.e. using req.perm.has_permission('TRAC_ADMIN') instead of 'TRAC_ADMIN' in req.perm, but it didn't help. After each change I rebuilt and reinstalled the .egg, and restarted the web server.

Please let me know if you have any other ideas, but failing that I think the next stop has to be the debugger. At this point I can't even be sure that any of the plugin code is being executed.

### comment:5 follow-up:  6 Changed 8 years ago by robert_martin

It might be worthwhile opening a small debugging file from the __init.py__ script, and doing the same from the body of htgroupeditor.py. It'll have to be to a place where trac has write permissions. There's a debug write function left commented out.

Would it be worthwhile making a copy of one of the ones that works and cut it down to just the get_admin_panels, check that works, then rename it and start adding bits of this plugin to the point it breaks??

Could there be any error messages in any of the apache log files?

### comment:6 in reply to:  5 Changed 8 years ago by Andrew Schulman

It might be worthwhile opening a small debugging file from the __init.py__ script, and doing the same from the body of htgroupeditor.py. It'll have to be to a place where trac has write permissions. There's a debug write function left commented out.

Yes, I did that. And the file is not being created. So it seems that the plugin code is not even being run, which means it's a configuration problem with my web server, and not a bug in the plugin at all. Sorry about that. I will finish running this down and get back to you with the result.

Would it be worthwhile making a copy of one of the ones that works and cut it down to just the get_admin_panels, check that works, then rename it and start adding bits of this plugin to the point it breaks??

Yes, that might help.

Could there be any error messages in any of the apache log files?

No, none.

### comment:7 Changed 8 years ago by robert_martin

Ah. Just re-read your first e-mail. Try installing it using the web page Admin/Plugins. It should then appear on there. Click on it and make sure the enabled check-box is ticked.

### comment:8 follow-up:  9 Changed 8 years ago by robert_martin

Correction - I should have put Admin/General/Plugins

You may want to un-install or delete the plugin from the command line first. I guess that when it is installed through the web interface it will also register itself in someway with Trac.

### comment:9 in reply to:  8 Changed 8 years ago by Andrew Schulman

Correction - I should have put Admin/General/Plugins

You may want to un-install or delete the plugin from the command line first. I guess that when it is installed through the web interface it will also register itself in someway with Trac.

Thanks for the suggestion. I tried it - removed the old .egg file from the project directory (/EPA/trac/plugins, where I had moved it from /EPA/usr/lib/python2.4/site-packages). Restarted the web server, then went to admin/general/plugin and uploaded the .egg file. Trac accepted it, and installed it afresh into /EPA/trac/plugins - but it still doesn't show up in the list of available plugins. :(

Debugging web applications in Python seems to be hard, and I wasn't able to make any headway with your other suggestion, of starting with a working plugin and transforming it into this one. At some point that process did fail, but there were too many moving parts for me to make any sense of it.

I may just be stuck with this problem as long as I'm stuck with Python 2.4. Seems quite dated now but I'm on RHEL5 and that's what they have. I could install Python 2.6 from source, but that's probably more work than it's worth.

I do appreciate your help on this.

### comment:10 Changed 8 years ago by Andrew Schulman

OK, I made some progress on this. By turning the log level in Trac up to DEBUG, I got the following message:

Trac[loader] DEBUG: Skipping "TracHtGroupEditorPlugin 2.0": ("DistributionNotFound: configobj" not found)


So this looks like some kind of PYTHONPATH problem. configobj is installed as /EPA/usr/lib/python2.4/site-packages/configobj.py.

$echo$PYTHONPATH
/EPA/usr/lib64/python2.4/site-packages:/EPA/usr/lib/python2.4/site-packages

$python Python 2.4.3 (#1, Jun 11 2009, 14:11:15) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import configobj >>> configobj <module 'configobj' from 'configobj.pyc'>  My web server has the same PYTHONPATH set, and configobj.py and all of its parent directories are world-readable and -executable. All of this is as I mentioned in my initial report. Ideas? Thanks, Andrew. ### comment:11 Changed 8 years ago by Andrew Schulman Indeed, mod_python.testhandler in Apache confirms that sys.path includes /EPA/usr/lib/python2.4/site-packages. And I have $ ls -l /EPA/usr/lib/python2.4/site-packages/{configobj,validate}*
-rw-rw-r-- 1 CEPApqk oecau07a 88163 Feb 27 16:36 /EPA/usr/lib/python2.4/site-packages/configobj.py
-rw-rw-r-- 1 CEPApqk oecau07a 64531 Jun 18 08:26 /EPA/usr/lib/python2.4/site-packages/configobj.pyc
-rw-rw-r-- 1 CEPApqk oecau07a 46324 Mar  1 18:04 /EPA/usr/lib/python2.4/site-packages/validate.py
-rw-rw-r-- 1 CEPApqk oecau07a 45733 Jun 18 08:26 /EPA/usr/lib/python2.4/site-packages/validate.pyc


### comment:12 Changed 8 years ago by Andrew Schulman

Resolution: → invalid assigned → closed

Well, I finally found the problem and got the plugin to work. Although I had installed configobj, I had used 'python setup.py install' to install it. That copied the files into what should have been the right places, but for some reason, htgroupeditor wanted to find it as an egg file. So I ran 'python setup.py install' for htgroupeditorplugin, and let it find and install configobj, which it did as an egg. Now it works.

Thanks for your time. I'm marking this bug as invalid and closing it.

### Modify Ticket

Change Properties