Mike Looijmans wrote:
> Inspired by our FieldStorage work with file uploads, I also made some
> implementation changes to Field and StringField in util.py. In essense,
> that will make things like using form['key'] multiple times much more
> efficient. Also, FieldStorage will return the same object if called twice.
>
> I'd like some feedback from the group on these changes, and also some
> directions on what I'd need to do to get them integrated in the
> mod_python beta. I have no experience whatsoever in contributing to open
> source projects.

I think it's too late in the beta cycle to be rewriting code unless it's
to fix a specific, critical bug. We really, really, *really* need to
deliver 3.2 final, and I don't want to mess with working code at this
point. The changes you are suggesting are likely more appropriate for
3.3, or possibly a 3.2 bugfix release.

As far as contributing to mod_python, well, I think you already have the
right idea: propose changes; discuss on python-dev; seek consensus; wait
for your changes to be committed by myself or Nicolas. Bug fixes and
code improvements are much more likely to be accepted than major new
features. We want mod_python to be tightly focused on the core
functionality of providing a Python interface to apache. The fancy bells
and whistles are best left to frameworks that utilize mod_python further
up the application stack.

For your specific changes, I would strongly suggest that you make your
changes against the mod_python development branch, ie trunk. Also people
are much more likely to test your changes if you submit a patch rather
than offering a completely new file. This makes it easier to see what
code is being changed and avoids problems with regressions.

I've put together a "Developer's Guide" draft that I'd like to
eventually see included in either the documentation or on the website.
This document doesn't represent any offical position of the mod_python
developers, but rather just what I see as best practices and some
resources for contributors. Everyone should feel free to offer
suggestions to improve this guide. The original is in svn at:
http://svn.apache.org/repos/asf/htt...>
rs-guide.rst

And no, I have not spell checked it yet. 

Regards,
Jim

[ Post a follow-up to this message ]

Ok, following Jim's advice, an having read his guide, I have so far:
- Fetched the trunk version with anonymous SVN (no problem)

I've already installed apache 2.0.55 and Python 2.4.1 on this Windows
machine (the lazy way, with MSI packages).

I've also installed the latest Cygwin (all "default" packages).

However, I'm not getting anywhere in compiling mod_python. It requires
the apxs tool which is apparently not part of any Apache windows
distribution. So I grabbed the apache 2.0.55 source for windows, but the
configure script is now stuck for over half an hour on:

Configuring Apache Portable Runtime Utility library...

checking for APR-util... reconfig
configuring package in srclib/apr-util now

Nothing appears to happen.

Anyone here who can help me out getting this up and running on Windows XP?

I can also use linux machines for compile and tests (I'm not root on
any), but I do most development on this Windows system, so I need a
windows executable anyway.

PS: Haven't found any speling errors in your document...

Jim Gallacher wrote:
> Mike Looijmans wrote:
> 
>
>
> I think it's too late in the beta cycle to be rewriting code unless it's
> to fix a specific, critical bug. We really, really, *really* need to
> deliver 3.2 final, and I don't want to mess with working code at this
> point. The changes you are suggesting are likely more appropriate for
> 3.3, or possibly a 3.2 bugfix release.
>
> As far as contributing to mod_python, well, I think you already have the
> right idea: propose changes; discuss on python-dev; seek consensus; wait
> for your changes to be committed by myself or Nicolas. Bug fixes and
> code improvements are much more likely to be accepted than major new
> features. We want mod_python to be tightly focused on the core
> functionality of providing a Python interface to apache. The fancy bells
> and whistles are best left to frameworks that utilize mod_python further
> up the application stack.
>
> For your specific changes, I would strongly suggest that you make your
> changes against the mod_python development branch, ie trunk. Also people
> are much more likely to test your changes if you submit a patch rather
> than offering a completely new file. This makes it easier to see what
> code is being changed and avoids problems with regressions.
>
> I've put together a "Developer's Guide" draft that I'd like to
> eventually see included in either the documentation or on the website.
> This document doesn't represent any offical position of the mod_python
> developers, but rather just what I see as best practices and some
> resources for contributors. Everyone should feel free to offer
> suggestions to improve this guide. The original is in svn at:
> http://svn.apache.org/repos/asf/htt...
pers-guide.rst
>
>
> And no, I have not spell checked it yet. 

[ Post a follow-up to this message ]

Mike Looijmans wrote:

> Ok, following Jim's advice, an having read his guide, I have so far:
> - Fetched the trunk version with anonymous SVN (no problem)
>
> I've already installed apache 2.0.55 and Python 2.4.1 on this Windows
> machine (the lazy way, with MSI packages).
>
> I've also installed the latest Cygwin (all "default" packages).
>
> However, I'm not getting anywhere in compiling mod_python. It requires
> the apxs tool which is apparently not part of any Apache windows
> distribution. So I grabbed the apache 2.0.55 source for windows, but
> the configure script is now stuck for over half an hour on:
>
> Configuring Apache Portable Runtime Utility library...
>
> checking for APR-util... reconfig
> configuring package in srclib/apr-util now
>
> Nothing appears to happen.
>
> Anyone here who can help me out getting this up and running on Windows
> XP?

See my other mail - basically you do
cd dist
set APACHESRC=c:\path\to\apache  (where this is the Apache2 dir in a
standard installation, now need for apache source)
build_installer

Unfortunately I haven't got the tests working yet, but this produces an
installer in dist/dist/

I wonder if it would be a good idea to have a wiki for mod_python, it
can be a nice way of collecting documentation...

David

>
> I can also use linux machines for compile and tests (I'm not root on
> any), but I do most development on this Windows system, so I need a
> windows executable anyway.
>
> PS: Haven't found any speling errors in your document...
>
> Jim Gallacher wrote:
> 
>
>

[ Post a follow-up to this message ]

David Fraser wrote:

> See my other mail - basically you do
> cd dist
> set APACHESRC=c:\path\to\apache  (where this is the Apache2 dir in a
> standard installation, now need for apache source)
> build_installer

Okay, first I downloaded the .NET SDK. (Our internet connection is great
here)

Then I get:

error: Python was built with version 7.1 of Visual Studio, and
extensions need to be built with the same version of the compiler, but
it isn't installed.

I don't have a VS license - that would mean I have to build my own
Python in order to get any further. Oh dear...

I was wondering - since i won't be hackin' the C code (yet), would it be
sufficient to just install the binary, and use the .py files as obtained
from the SVN repository?

The 3.2.5 beta seems to run just fine here. Cannot run the automated
tests though, because of the issues mentioned above.

[ Post a follow-up to this message ]

Mike Looijmans wrote:

> David Fraser wrote:
> 
>
> Okay, first I downloaded the .NET SDK. (Our internet connection is
> great here)
>
> Then I get:
>
> error: Python was built with version 7.1 of Visual Studio, and
> extensions need to be built with the same version of the compiler, but
> it isn't installed.
>
> I don't have a VS license - that would mean I have to build my own
> Python in order to get any further. Oh dear...

Strange, I have VS.NET 2003 installed here, and it doesn't give errors.
I think I got mod_python compiling at one stage with mingw so that is
the other route you could go...

> I was wondering - since i won't be hackin' the C code (yet), would it
> be sufficient to just install the binary, and use the .py files as
> obtained from the SVN repository?
>
Yes you should be able to install the binary and run the tests from the
repository (if you can get past the issues I had running them ...)

> The 3.2.5 beta seems to run just fine here. Cannot run the automated
> tests though, because of the issues mentioned above.

Cheers
David

[ Post a follow-up to this message ]