headers
Phillip J. Eby | 5 Oct 2004 17:12
Gravatar

peak.web in October

As some of you may have noticed from last week's flurry of checkins, I'm 
finally doing the peak.web refactoring I've been talking about off and on 
for the last several months.  At this point, the plan is to complete at 
least these peak.web "Tier 1" features this month:

  * Overhauled traversal system to be fast, flexible, and extensible (DONE)

  * Add a "views" subsystem that allows you to declare how traversals will 
be interpreted for arbitrary objects in arbitrary subparts of a site, 
without creating a decorator class (DONE)

  * Overhaul PWT to use the new this:/content: attribute mechanism 
(Started; the needed XML parser is in a draft status)

  * Design and implement an XML dialect for site configuration, similar in 
functionality to Zope 3's ZCML, but with the capability of structuring a 
site or application's URL layout and "local" as well as "global" 
configuration.  (Not started, but will use the same draft XML parser)

  * Create view registration mechanisms for both .ini files and .xml files

  * Implementation that can be plugged into any WSGI (PEP 333) compatible 
web server

  * All of PEAK's internal web gateways (CGI, FastCGI, and local_server) 
will offer a WSGI interface for running other applications

  * PEAK will be distributed with a WSGI reference library

  * Miscellaneous cleanups and minor features, such as adding the ability
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phillip J. Eby | 5 Oct 2004 20:55
Gravatar

peak.web site configuration

[As always, your comments and questions are welcome and requested.]

Requirements
============

These requirements mainly address Tier 1 functionality, with a few notes on 
higher-tier items that could maybe be done sooner.

High Priority
-------------

* Define locations, beginning with the application's root

* Define views for objects of a particular type or interface, that are 
applicable within the current location, along with their required permission(s)

   - Define a view's implementation by specifying a resource name

   - Define a view's implementation by specifying a Python expression

* Declare the permissions required within the current location to access 
attributes of objects of a particular type or interface

* Extensible format: should be easy to add new kinds of registration and 
declaration within pretty much arbitrary locations.

* Have a way to specify that a given location will look for subobjects 
using certain Python mappings or functions (akin to the Specialist->Rack 
mapping in ZPatterns)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 6 Oct 2004 03:32
Gravatar

Anybody using 'running.IRerunnableCGI'?

Is anybody using the 'IRerunnableCGI' interface, either implementing it 
directly (as in 'examples/trivial_cgi'), or using it in some other way?

Now that PEP 333 is stabilizing, I'd like to ditch IRerunnableCGI in favor 
of an 'IWSGIApplication' interface basd on PEP 333.  In the process, I'll 
be wanting to refactor all of PEAK's commands and containers that use 
IRerunnableCGI to use the new interface.

For most of these, I could possibly write an adapter from IWSGIApplication 
to IRerunnableCGI, and then just deprecate IRerunnableCGI until the next 
release, but I'd rather not bother with maintaining the backward 
compatibility if nobody's using it.

Please try to let me know soon if you'd like to make a case for retaining 
the old interface through the next release.  I'm working right now on the 
library that will be used to implement PEAK's WSGI gateways.
Permalink | Reply | 2 comments |
headers
Ulrich Eck | 6 Oct 2004 10:24
Picon

Re: Anybody using 'running.IRerunnableCGI'?

Hey Phillip,

your plans for peak.web sound very promising.

all my projects that used peak.web were only for testing purposes,
so for my part .. just go ahead with refactoring p.w. .. i'll have
to adjust my stuff in any way to make it work with p.w.NG

cheers
Ulrich

On Wed, 2004-10-06 at 03:32, Phillip J. Eby wrote:
> Is anybody using the 'IRerunnableCGI' interface, either implementing it 
> directly (as in 'examples/trivial_cgi'), or using it in some other way?
> 
> Now that PEP 333 is stabilizing, I'd like to ditch IRerunnableCGI in favor 
> of an 'IWSGIApplication' interface basd on PEP 333.  In the process, I'll 
> be wanting to refactor all of PEAK's commands and containers that use 
> IRerunnableCGI to use the new interface.
> 
> For most of these, I could possibly write an adapter from IWSGIApplication 
> to IRerunnableCGI, and then just deprecate IRerunnableCGI until the next 
> release, but I'd rather not bother with maintaining the backward 
> compatibility if nobody's using it.
> 
> Please try to let me know soon if you'd like to make a case for retaining 
> the old interface through the next release.  I'm working right now on the 
> library that will be used to implement PEAK's WSGI gateways.
> 
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 8 Oct 2004 02:45
Gravatar

WSGI support now available (was Re: peak.web in October)

At 11:12 AM 10/5/04 -0400, Phillip J. Eby wrote:
>* Implementation that can be plugged into any WSGI (PEP 333) compatible 
>web server
>
>  * All of PEAK's internal web gateways (CGI, FastCGI, and local_server) 
> will offer a WSGI interface for running other applications
>
>  * PEAK will be distributed with a WSGI reference library

These tasks are now complete.  'peak.web' applications are now WSGI 
applications, and all of PEAK's internal web gateways ("peak launch", "peak 
serve", "peak CGI", and "peak supervise") can now run any WSGI application.

PEAK is now distributed with a WSGI reference library, 'wsgiref', and all 
of PEAK's demo apps and tool apps (such as 'ddt.web' and 'ddt.view') are 
now WSGI applications.

For more information, see:

    http://mail.python.org/pipermail/web-sig/2004-October/000966.html

    http://www.eby-sarna.com/pipermail/source-changes/2004q4/001842.html

and the first three entries of:

    http://cvs.eby-sarna.com/PEAK/CHANGES.txt?rev=1.149&content-type=text/vnd.viewcvs-markup

Enjoy!
Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 8 Oct 2004 02:48
Gravatar

Re: Anybody using 'running.IRerunnableCGI'?

At 09:32 PM 10/5/04 -0400, Phillip J. Eby wrote:
>Now that PEP 333 is stabilizing, I'd like to ditch IRerunnableCGI in favor 
>of an 'IWSGIApplication' interface basd on PEP 333.  In the process, I'll 
>be wanting to refactor all of PEAK's commands and containers that use 
>IRerunnableCGI to use the new interface.
>
>For most of these, I could possibly write an adapter from IWSGIApplication 
>to IRerunnableCGI, and then just deprecate IRerunnableCGI until the next 
>release, but I'd rather not bother with maintaining the backward 
>compatibility if nobody's using it.

Sorry, false alarm.  We're keeping IRerunnableCGI after all.  It turned out 
when I actually got into the code, it made perfect sense to keep 
IRerunnableCGI around for the subsystems (apart from WSGIServer) that used 
it before, as they are fundamentally CGI-based.  So, I just wrote the 
adapter and made everything else use IWSGIApplication.
Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 8 Oct 2004 19:33
Gravatar

Re: Packaging peak apps

At 11:18 AM 9/28/04 -0400, Phillip J. Eby wrote:
>Also note that even if your script got to the second line, it would then 
>run afoul of the fact that 'config.fileNearModule()' will be broken when 
>the modules are in a zipfile.
>
>Really, to run from a zipfile, you not only need the currently 
>non-existent Python 2.3.5, but also a version of PEAK that doesn't use 
>fileNearModule() in its present form.

FYI, that version of PEAK is now in CVS.  'config.fileNearModule()' is now 
deprecated and its usage in the PEAK libraries has been converted to 
'config.packageFile()', which is able to work with PEP 302 loaders that 
have a 'get_data()' method (such as the zipfile import loader in Python 2.3 
and up).

This *doesn't* address the lazy-import issue with Python's reload() bugs, 
but it *does* mean that PEAK should be able to read all its configuration 
files, schemas, etc. from a zipfile that has them compressed within the 
appropriate subdirectories.  Likewise, PEAK applications that use 
'pkgfile:' URLs should also be able to work zipped.

So, it seems the only hurdle left to being able to use PEAK with py2exe and 
friends is the reload() fixes.  (And possibly with getting py2exe to zip up 
package data files, in case it currently only puts modules in the zipfile.)
Permalink | Reply | 15 comments |
headers
Bob Ippolito | 8 Oct 2004 21:23
Gravatar

Re: Packaging peak apps


On Oct 8, 2004, at 1:33 PM, Phillip J. Eby wrote:

> At 11:18 AM 9/28/04 -0400, Phillip J. Eby wrote:
>> Also note that even if your script got to the second line, it would 
>> then run afoul of the fact that 'config.fileNearModule()' will be 
>> broken when the modules are in a zipfile.
>>
>> Really, to run from a zipfile, you not only need the currently 
>> non-existent Python 2.3.5, but also a version of PEAK that doesn't 
>> use fileNearModule() in its present form.
>
> FYI, that version of PEAK is now in CVS.  'config.fileNearModule()' is 
> now deprecated and its usage in the PEAK libraries has been converted 
> to 'config.packageFile()', which is able to work with PEP 302 loaders 
> that have a 'get_data()' method (such as the zipfile import loader in 
> Python 2.3 and up).
>
> This *doesn't* address the lazy-import issue with Python's reload() 
> bugs, but it *does* mean that PEAK should be able to read all its 
> configuration files, schemas, etc. from a zipfile that has them 
> compressed within the appropriate subdirectories.  Likewise, PEAK 
> applications that use 'pkgfile:' URLs should also be able to work 
> zipped.
>
> So, it seems the only hurdle left to being able to use PEAK with 
> py2exe and friends is the reload() fixes.  (And possibly with getting 
> py2exe to zip up package data files, in case it currently only puts 
> modules in the zipfile.)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Phillip J. Eby | 8 Oct 2004 21:40
Gravatar

Re: Packaging peak apps

At 03:23 PM 10/8/04 -0400, Bob Ippolito wrote:

>There is currently no standard way to determine what files a package 
>actually *needs*, versus what files happen to be in there (such as 
>documentation, version control junk, etc.)... so correctly packaging up 
>stuff that requires data files is going to require developing some 
>manifest file or something that says "i need these files".  Preferably 
>this file would be parseable without eval'ing arbitrary python code.
>
>If you come up with something that makes sense, I'll support usage of it 
>in py2app and try and get it supported by at least Twisted and pygame.

Well, for the application being generated, the setup.py will specify what 
"package data" files are valid, so in the case of py2app you can just use 
the distribution object's data to get at that.  The build_py command 
handles generating the actual list.

For already-installed packages, PEP 262 defines an installation manifest 
that would record the data, and in principle should eventually be 
implemented for package data files.

So, my suggestion would be to implement PEP 262 as an add-on to 
'setuptools', and then we're good to go.  ;)

Of course, to do that, we'll probably need to hash some things out on the 
Distutils SIG.  I think I'd want to propose dropping the REQUIRES and 
PROVIDES sections, and of course all my "open issues" listed in the PEP.

What do you think?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bob Ippolito | 8 Oct 2004 22:58
Gravatar

Re: Packaging peak apps


On Oct 8, 2004, at 3:40 PM, Phillip J. Eby wrote:

> At 03:23 PM 10/8/04 -0400, Bob Ippolito wrote:
>
>> There is currently no standard way to determine what files a package 
>> actually *needs*, versus what files happen to be in there (such as 
>> documentation, version control junk, etc.)... so correctly packaging 
>> up stuff that requires data files is going to require developing some 
>> manifest file or something that says "i need these files".  
>> Preferably this file would be parseable without eval'ing arbitrary 
>> python code.
>>
>> If you come up with something that makes sense, I'll support usage of 
>> it in py2app and try and get it supported by at least Twisted and 
>> pygame.
>
> Well, for the application being generated, the setup.py will specify 
> what "package data" files are valid, so in the case of py2app you can 
> just use the distribution object's data to get at that.  The build_py 
> command handles generating the actual list.

Well py2app wouldn't have access to PEAK's setup.py at the point where 
it wants to determine the dependencies for the peak package.

> For already-installed packages, PEP 262 defines an installation 
> manifest that would record the data, and in principle should 
> eventually be implemented for package data files.
>
> So, my suggestion would be to implement PEP 262 as an add-on to
(Continue reading)

Permalink | Reply | 2 comments |

Gmane