Re: Solving the import problem
Graham Dumpleton wrote: On 10/06/2005, at 2:53 AM, dharana wrote: As for vampire - why would I want vampire? mod_python is great except this. I personally have no interest in adding yet more software to my system just to solve the mod_python import issue - Id rather it was fixed in the right place...not everyone uses vampire... I really get annoyed by so much Vampire ads everywhere. I understand it's developers have spent considerable time in it but I think people who come to python for webdev from an easier framework do it because they want _more_ control, not less (at least that is my case). I am happy with my custom framework in python now, it didn't took me a lot of time and it's tuned for my needs. I won't look into using Vampire for that reason. Vampire is not about giving you less control, it is actually the opposite. It gives you more glue components and hooks so as to give you more control and more and better ways of doing things over what mod_python by itself provides. It is not just some monolithic blob and isn't intended to be a framework where you are restricted to working in a certain way. I'll quit with the advocacy if that is what people want, but it gets pretty disheartening when you see people on the mailing list trying to solve problems, and not really understanding properly how to do it, when Vampire already provides an example of how to do it or a pre-canned solution, yet you can't even get them too look at it. I have continually found that it is like the saying you can lead a horse to water, but you can't make it drink. :-) I'll shut up for a while now. I think it's great you've solved some of these problems in Vampire... Some of the solutions should definitely be brought back into mod_python, using Vampire as a staging ground for mod_python improvements as you recommended earlier. David
Re: svn commit: r189572 - /httpd/httpd/trunk/CHANGES
On Wed, Jun 08, 2005 at 08:37:50AM -0700, Paul Querna wrote: I believe that we should be keeping items in the 2.1.x changelog at this point, since we have done several releases Ah, sorry, I remember the discussion about this previously but didn't remember if there was consensus on what to do. So we should just not bother synching up the 2.0.x CHANGES in the trunk at all? I think that makes sense. joe
Re: svn commit: r189572 - /httpd/httpd/trunk/CHANGES
On 6/9/05, Joe Orton [EMAIL PROTECTED] wrote: On Wed, Jun 08, 2005 at 08:37:50AM -0700, Paul Querna wrote: I believe that we should be keeping items in the 2.1.x changelog at this point, since we have done several releases Ah, sorry, I remember the discussion about this previously but didn't remember if there was consensus on what to do. So we should just not bother synching up the 2.0.x CHANGES in the trunk at all? I think that makes sense. I thought there were more in favor of the other alternative, but I don't think it is so important either way, as long as everybody knows (2.0.x/STATUS???) to do the same thing.
displaying thread id in mod_status ExtendedStatus table - how to request it?
motivation: correlate stuck requests seen in mod_status display with entries in third-party logs which log pid+tid I assume that simply adding another column to the table will break existing scripts. Requre threadid in query argument to see this information? (/server-status/?notablethreadid or something like that) Have a query argument that tells mod_status to always spit out all available information? format may change if somebody adds a new column in the future (/server-status/?refresh=5showall)
Re: Solving the import problem
On 09/06/2005, at 4:38 PM, Nicolas Lehuen wrote: Erm, so, no, handlers could also be imported from the document tree. No problem, we can do that, but the security issues pop up once again. We can't protect against everything though. ;-) I've understood you point, but there is a difficulty in judging from a PythonHandler directive whether the handler should be loaded as a standard Python module, from the sys.path, or as a dynamic Python module, from the document tree. Maybe the context of the directive could be used for that ; if the directive is defined at the server or virtual host level, then it's a top level handler, otherwise if it is defined in a Location or Directory (or .htaccess file), then it's a handler that should be loaded from the document tree (with a possible fallback to sys.path if it is not found ?). If PythonImport is used, it can only come from sys.path as there is no connection with a physical directory. Similar with PythonHandler which is defined in a Location directive, there is no connection with a directory and thus can only come from sys.path. Thus, only where the Directory directive is used, or PythonHandler is specified in the actual .htaccess file do we have a physical directory and can use apache.import_module(). Anyway, saying that import should be used to import from the sys.path and apache.import_module should be used to import from the document tree looks like a clean rule, easy to understand and to implement. The suggestion I've made in my former (way too long) mail was simply that when a module is not found from the document tree, we could fall back to a careful standard import from the sys.path, but this would smudge in appearance this clean separation between standard and dynamic modules. At the moment I am a bit worried about falling back on sys.path in apache.import_module() itself, partly because it confuses the two concepts, but not sure there aren't some strange problems lurking in there as well if that was done. What can be considered though is an alternative fallback search path, one that is distinct from sys.path but where mod_python style module loading is used if the module is found in the alternate path. I have implemented this in Vampire to see how it might work in practice. The main thing that it allows is for utility code to use apache.import_module() without the need to have to look up some special configuration mechanism to determine a special directory from which it should otherwise load from. Jury is out on this one at the moment though as to whether it is a good idea or not. :-) Time now to start bringing up some of the other issues that have to be dealt with. The first is that the current apache.import_module() is able to support packages to a degree, its not perfect though as is evidenced I think by problems importing mod_python.psp. This is more though to do with it not setting up the import exactly as the standard Python module importer requires it look. If apache.import_module() doesn't use sys.modules it will not matter if the way it sets things up as long as it is able to provide the same behaviour. The question you might be asking is do we need to support packages. Well, its a question I am not sure I have a good answer for. I know I have seen people posting on the mailing list with examples of package use, eg: http://www.modpython.org/pipermail/mod_python/2005-May/018182.html In that case though they were using from/import and not actually using apache.import_module(). They did have the package stored in the document tree though. So, not sure if in practice people are using packages with apache.import_module() or not. If packages were supported there would still be a few things to do. First is that the module loader when given a module name which equates to the name of a directory would need to see if the directory contains a __init__.py file and if it does, load that file as the module. The big problem now is that if the __init__.py file uses standard import statement with the expectation that it will grab the module or package from within the same directory, it will not work. This is because to the Python import system it will not know that it is to be treated as a package and look in that local directory first. I got past this problem in Vampire through the use of the import hook. Vampire would stash a special global object in the module so the import hook knew that it was a special Vampire managed module and would grab the module from the local directory and import it using the Vampire module importing system rather than standard Python module importer. At the moment though this only works at global scope and not when import is used in the handler code when executed, although can probably solve that. Although from/import syntax also works, if it tried to import a.b from a subpackage, it will not work if b wasn't explicitly imported by a to begin with. In summary, haven't been able to get package imports to work
Re: svn commit: r189761 - /httpd/httpd/branches/fips-dev/acinclude.m4
On Thu, Jun 09, 2005 at 02:57:37PM -, [EMAIL PROTECTED] wrote: Author: ben Date: Thu Jun 9 07:57:36 2005 New Revision: 189761 URL: http://svn.apache.org/viewcvs?rev=189761view=rev Log: Die properly when path is bollocks. Did you mean to commit this to the branch? (given that it's not FIPS-specific) - test x == y is not portable, s/==/=/ - don't exit, use AC_MSG_ERROR and pass an error message - whitespace should be spaces not tabs Modified: httpd/httpd/branches/fips-dev/acinclude.m4 Modified: httpd/httpd/branches/fips-dev/acinclude.m4 URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/fips-dev/acinclude.m4?rev=189761r1=189760r2=189761view=diff == --- httpd/httpd/branches/fips-dev/acinclude.m4 (original) +++ httpd/httpd/branches/fips-dev/acinclude.m4 Thu Jun 9 07:57:36 2005 @@ -340,7 +340,10 @@ dnl If --with-sslc specifies a directory, we use that directory or fail if test x$withval != xyes -a x$withval != x; then dnl This ensures $withval is actually a directory and that it is absolute - ap_ssltk_base=`cd $withval ; pwd` + ap_ssltk_base=`cd $withval pwd` + if test x$ap_ssltk_base == x; then + exit + fi ...
A Document on import issues? Was: Solving the import problem
I find that I'm unable to follow the import discussion in an e-mail exchange format. This is a complex issue that requires a lot of things to be considered, researched, tested, etc. I find that as I read these e-mails I find points that are potentially contestable, but to meaningfully address them requires me to read the thread from the beginning and by then I lose track of what the point was. May I suggest that instead of continuing an e-mail thread that we instead try to write a paper/essay on the issue? This could be a text file in SVN somewhere or a wiki somewhere, doesn't really matter. The key thing is it would be better if we had a document that we could refer to and argue individual points on while the document represented the collection of all issues. Graham - since you've probably written the most on the subject - do you think you could volunteer to start it? I think ultimately this document could be placed in the Doc directory so that future generations could read why mod_python does importing a certain (yet to be determined) way. Grisha
Re: svn commit: r189761 - /httpd/httpd/branches/fips-dev/acinclude.m4
Joe Orton wrote: On Thu, Jun 09, 2005 at 02:57:37PM -, [EMAIL PROTECTED] wrote: Author: ben Date: Thu Jun 9 07:57:36 2005 New Revision: 189761 URL: http://svn.apache.org/viewcvs?rev=189761view=rev Log: Die properly when path is bollocks. Did you mean to commit this to the branch? (given that it's not FIPS-specific) Well, I should probably also commit to the head, its true. But I hope the long-term plan will be to take the whole FIPS branch to head. - test x == y is not portable, s/==/=/ OK. - don't exit, use AC_MSG_ERROR and pass an error message OK. autoconf sucks. - whitespace should be spaces not tabs OK. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: displaying thread id in mod_status ExtendedStatus table - how to request it?
At 05:03 AM 6/9/2005, Jeff Trawick wrote: motivation: correlate stuck requests seen in mod_status display with entries in third-party logs which log pid+tid +1, was bit by this issue myself a week ago(!) I assume that simply adding another column to the table will break existing scripts. Requre threadid in query argument to see this information? (/server-status/?notablethreadid or something like that) Have a query argument that tells mod_status to always spit out all available information? format may change if somebody adds a new column in the future (/server-status/?refresh=5showall) Or name the columns? Better yet, move to an XML output (?refresh=5display=xml) which any decent parser can tear apart, no matter how we change things in the future? I like the idea of toggling columns, I'd make it more like columns=pid,tid,ss,m,req to allow for abbreviated displays. One other thing, we should probably contemplate disallowing certain fields. E.g. someone who wanted server-status, but didn't want to leak pid/tid or remote IP information might want to lock out those fields from being returned. Bill
