Webware for Python

On 4/1/06, Christoph Zwerschke <cito@...> wrote:
> Since a couple of bugs have been fixed in the last months and a nice
> Ajax example was added, I think it is time for making a new 0.9.1
> release. However, one thing I would like to have in the new release is
> the (optional) use of polling instead of ImportSpy, something that has
> been discussed several times, because ImportSpy has issues with
> importing Cheetah templates, Python eggs etc. Anybody here willing to
> implement this? Otherwise I might have a try, which could be worse ;-)
>
> Other things that should be fixed/added to a 0.9.1 release?

The polling could go into a 0.9.2. One problem that has vexed Webware
is that releases go weeks or even months without getting released so
one more thing can be added. In the mean time, people download the old
release and miss all the good stuff that's sitting in the repository.

That's my 2 cents.

-Chuck

Chuck Esterbrook wrote:
> The polling could go into a 0.9.2. One problem that has vexed Webware
> is that releases go weeks or even months without getting released so
> one more thing can be added. In the mean time, people download the old
> release and miss all the good stuff that's sitting in the repository.

My idea was to add the polling next weekend (if nobody else does it) and 
make it optional in version 0.9.1, so it will not break anything, but 
people will be able to test and improve it. If it turns out to be better 
than the current approach, we can then make it the standard in 0.9.2. If 
I don't find the time to do it or it turns out to be too complicated, I 
can make a new release next weekend anyway. Would that be ok?

-- Christoph

On 4/2/06, Christoph Zwerschke <cito@...> wrote:
> Chuck Esterbrook wrote:
> > The polling could go into a 0.9.2. One problem that has vexed Webware
> > is that releases go weeks or even months without getting released so
> > one more thing can be added. In the mean time, people download the old
> > release and miss all the good stuff that's sitting in the repository.
>
> My idea was to add the polling next weekend (if nobody else does it) and
> make it optional in version 0.9.1, so it will not break anything, but
> people will be able to test and improve it. If it turns out to be better
> than the current approach, we can then make it the standard in 0.9.2. If
> I don't find the time to do it or it turns out to be too complicated, I
> can make a new release next weekend anyway. Would that be ok?
>
> -- Christoph

Sounds good.

-Chuck

I have just implemented a solution to the ImportSpy problem.

ImportSpy used ihooks to track imported modules, in order to reload 
those modules with AutoReloadingAppServer. The problem was that using 
ihooks could raise problems if you used Cheetah templates or imported 
modules like Kid from zipped Python eggs, since these new importers are 
not compatible with ihooks.

I have tackled the problem from two sides:

First, ImportSpy now uses new (PEP 302) import hooks instead of ihooks 
if available (i.e. since Python 2.3). The compatibility issues should be 
solved now. Second, everything from ImportSpy except the import hook 
itself has been sourced out to a new ImportManager module. Loading and 
using ImportSpy can not be completely suppressed by setting 
"UseImportSpy" to False in Application.config (or would AppServer.config 
be better?). If ImportSpy is not used, sys.modules is polled instead. By 
default, this is set to True, so we get the old behavior.

I will fix two or three more bugs on my list today and then make a 0.9.1 
beta release. Is this ok?

-- Christoph

Since I did not get much feedback, I'm going to release 0.9.1 final this 
weekend if nobody objects.

-- Christoph

On Apr 21, 2006, at 9:32 AM, Christoph Zwerschke wrote:

> Since I did not get much feedback, I'm going to release 0.9.1 final  
> this weekend if nobody objects.

FWIW, today I downloaded the 0.9.1b1 and installed it on Mac OS X  
10.4.6 running python 2.4. Ran through the tests without a hitch. Set  
up a working directory, added my app files, and fired it up also  
without a blip.

Thanks for all the great work these past months, Christoph!

Mark Phillips

* Christoph Zwerschke <cito@...> [060421 18:40]:
> Since I did not get much feedback, I'm going to release 0.9.1 final this 
> weekend if nobody objects.

I'm using 0.9.1 beta in productive environment without problems.

Just one minor issue:  starting with a 0.9pre release (if I remember
correctly) the MakeAppWorkDir.py script refused to write the application
skeleton when the target directory already existed.

I used to check out e.g. the "MyApp" directory from version control and
webware-ify it with "MakeAppWorkDir.py MyApp" afterwards.  This doesn't
work anymore, is there a specific reason for this behaviour?  I've no
problem working around this issue, but I don't like constraints without
having a decent motivation... ;-)

Thank you!
-- 
Andi

Andreas Poisel wrote:
> Just one minor issue:  starting with a 0.9pre release (if I remember
> correctly) the MakeAppWorkDir.py script refused to write the application
> skeleton when the target directory already existed.
> 
> I used to check out e.g. the "MyApp" directory from version control and
> webware-ify it with "MakeAppWorkDir.py MyApp" afterwards.

I have usually checked in everything that is needed (directory 
structure, config files and launcher), so that it runs out of the box 
without the need to "webware-ify" anything. This is not much overhead 
and it makes sense to save the config files anyway.

> This doesn't work anymore, is there a specific reason for this behaviour?
 > I've no problem working around this issue, but I don't like constraints
 > without having a decent motivation... ;-)

I can allow running on an existing working dir, but how should 
MakeAppWorkDir behave if the config files or the launcher script already 
exist? Overwrite or keep (there could be some customization in the 
config files and launcher script already)? Maybe we can add an option 
--overwrite, but what should be the default?

-- Christoph

Mark Phillips wrote:
> FWIW, today I downloaded the 0.9.1b1 and installed it on Mac OS X 10.4.6 
> running python 2.4. Ran through the tests without a hitch. Set up a 
> working directory, added my app files, and fired it up also without a blip.

That's an important feedback since I've run and tested Webware only on 
Linux, Win and Solaris :-) It would be also interesting to know whether 
mod_webkit runs on Mac OS (which has a built in Apache server, right)?

-- Christoph

On Apr 22, 2006, at 1:45 AM, Christoph Zwerschke wrote:

> That's an important feedback since I've run and tested Webware only  
> on Linux, Win and Solaris :-) It would be also interesting to know  
> whether mod_webkit runs on Mac OS (which has a built in Apache  
> server, right)?

Yes. I have Apache2 installed on the target server, and Mac OS X does  
comes with Apache v1 installed in the standard distro. I have set up  
one apache2 mod for developing with another tool set. There are a few  
things left to do so the test users can exercise it.

I will try the two mod_webkits for apache once the users are taken  
care of.

  - Mark

> I can allow running on an existing working dir, but how should
 > MakeAppWorkDir behave if the config files or the launcher script
 > already exist? Overwrite or keep (there could be some customization
 > in the config files and launcher script already)? Maybe we can add
 > an option --overwrite, but what should be the default?

Ok, I have already changed the MakeAppWorkDir script. If the working dir 
does already exist, then all missing subdirectories and files will be 
created, and access permissions set, but without overwriting any 
existing files. I think that is reasonable. If you want to recreate 
default config files or launcher scripts, you can simply delete them and 
run MakeAppWorkDir.

-- Christoph

* Christoph Zwerschke <cito@...> [060423 18:50]:

> Ok, I have already changed the MakeAppWorkDir script. If the working dir 
> does already exist, then all missing subdirectories and files will be 
> created, and access permissions set, but without overwriting any 
> existing files. I think that is reasonable. If you want to recreate 
> default config files or launcher scripts, you can simply delete them and 
> run MakeAppWorkDir.

Great!  Since I'm using different settings for a application on the
development machines, putting the Webware configuration files into
version control is not an option for me.

Thank you!
-- 
Andi