Bruce Dubbs wrote: > Bryan Kadzban wrote: > >> Based on this, I would *suspect* that you'd have to modify >> /root/accountmanager/acct_mgr/web_ui.py, then (somehow) rebuild the >> .egg file, then copy it to >> /usr/lib/python2.4/site-packages/<wherever> again. Maybe do some >> easy_installer stuff as well, I'm unsure. > > An egg is only a zip file with a different extension. I think that > these files are extracted to a cache and run from there, but I don't > know how a new file could be recognized.
I *believe* they're re-extracted every time they get imported, but I don't know for sure. > It appears that a .pyc file is automatically generated the first time > a .py file is run so, strictly speaking, you don't need to include > the .pyc file. Right, but for some reason, egg files do include the .pyc files in addition to the original .py. This makes no sense to me, but it's what "unzip -l" claims. ;-) > From the web: > > ".egg files are a "zero installation" format for a Python package; no > build or install step is required, just put them on PYTHONPATH or > sys.path and use them (may require the runtime installed if C > extensions or data files are used)" Yeah; you'll have to build the .egg file somehow though. Whether that involves just zipping up the .py/.pyc files in the same sort of setup as the current .egg, or it involves something else, I'm not sure. I saw a few references to easy_installer when doing a bit of looking on my own earlier. > The httpd conf file has: > > ... > setEnv PYTHON_EGG_CACHE /srv/trac/LFS/cache Assuming that actually works (I'm unsure if SetEnv affects the current Apache httpd process's environment, and thus that of mod_python, or if it only affects CGI subprocesses -- and the Apache docs don't really specify one or the other), that makes sense. > but the cache file doesn't have any .py or .pyc files. If the Python interpreter removes them after the module that imported the .egg is finished running, then this makes sense. Of course, that's a bunch of extra disk I/O... > I'll try to take a further look in the next couple of days. Thanks! It's not a huge deal for me now that I've jumped through the verification hoop, but I'd rather it get patched if possible. As it is, random other people won't be able to find out that this verification hoop even exists. ;-) > One more thing that I tried is to disable > acct_mgr.web_ui.emailverificationmodule in the trac configuration. > > Let me know if that workaround works for you. Well, as I was not getting the MessageWrapper messages anymore before this change happened, I can't tell. I suspect it will help, though, as it will get rid of the need to verify accounts' email addresses. If that verification is still wanted, then it seems like fixing the MessageWrapper class is the best. :-) Thanks!
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
