All,
Thanks, Jim and Ian, for bringing this discussion online.
I have two hesitations with Paste Deploy:
1. The configuration syntax is really complex. I'm much more
comfortable with multiple simpler config files.
2. I'm not clear on how Paste Deploy's abstractions map to the
> A standard "file format" for a website enables a wider tool
> ecosystem to evolve: interactive shells, debuggers, test
> runners, skel systems, configuration UIs.
Not to mention existing tools like workingenv, distutils, ...
___
Web-SIG mailing lis
I'll respond in a high-level way.
I believe, we're evaluating Paste Deploy at 2 levels:
1. Can we agree on a standard set of entry points so that WSGI
applications can be combined automatically? I think Paste Deploy
provides at least good start on this.
2. Do we want to reuse it's configur
Jim,
Thanks for the reply.
> 2. Do we want to reuse its configuration syntax.
-1
> The configuration format used by Paste Deploy is a simple
> standard format used by many many systems inside and outside
> the Python community.
I'm not objecting to the general ini-style format (do I read
Jim Fulton wrote:
> I believe, we're evaluating Paste Deploy at 2 levels:
> 1. Can we agree on a standard set of entry points so
> that WSGI applications can be combined automatically?
> I think Paste Deploy provides at least good start on this.
Yes, I think we can. And the ones in paste deploy ar
> Sure, as long as Paste Deploy's config syntax is optional for
> whatever-we're-building. :^)
Some of the pain and angst over choosing one solution to the WSGI
application composition problem could be treated by dividing the
composition process into (at least) three parts:
1. Configuration parsi
Jim Fulton wrote:
> I'll respond in a high-level way.
>
> I believe, we're evaluating Paste Deploy at 2 levels:
>
> 1. Can we agree on a standard set of entry points so that WSGI
> applications can be combined automatically? I think Paste Deploy
> provides at least good start on this.
>
> 2
Chad Whitacre wrote:
> All,
>
> Thanks, Jim and Ian, for bringing this discussion online.
>
> I have two hesitations with Paste Deploy:
>
>1. The configuration syntax is really complex. I'm much more
> comfortable with multiple simpler config files.
Is it really that complex? There's
Robert Brewer wrote:
> Jim Fulton wrote:
> > I believe, we're evaluating Paste Deploy at 2 levels:
> > 1. Can we agree on a standard set of entry points so
> > that WSGI applications can be combined automatically?
> > I think Paste Deploy provides at least good start on this.
>
> Yes, I think
L.C. Rees wrote:
>> Sure, as long as Paste Deploy's config syntax is optional for
>> whatever-we're-building. :^)
>
> Some of the pain and angst over choosing one solution to the WSGI
> application composition problem could be treated by dividing the
> composition process into (at least) three par
Ian,
Thanks for weighing in.
> >2. I'm not clear on how Paste Deploy's abstractions map to the
> > filesystem. What does my website root look like?
>
> The way I have generally configured websites like this is like:
>
>[composite:main]
>use = egg:Paste#urlmap
>/ = config:ro
Chad Whitacre wrote:
>> >2. I'm not clear on how Paste Deploy's abstractions map to the
>> > filesystem. What does my website root look like?
>>
>> The way I have generally configured websites like this is like:
>>
>>[composite:main]
>>use = egg:Paste#urlmap
>>/ = config:root.
> I don't think we should have any validation in the config format
> (except for basic syntax, of course). Doing validation is just too
> hard, and leads to a rather complex config framework. I think some
> of the problems with ZConfig come back to this.
I didn't propose that validation be i
On Mar 3, 2007, at 3:54 PM, Ian Bicking wrote:
> Chad Whitacre wrote:
>> All,
>>
>> Thanks, Jim and Ian, for bringing this discussion online.
>>
>> I have two hesitations with Paste Deploy:
>>
>>1. The configuration syntax is really complex. I'm much more
>> comfortable with multiple si
On Mar 3, 2007, at 11:09 AM, Chad Whitacre wrote:
...
> > 1. Can we agree on a standard set of entry points so that WSGI
> > applications can be combined automatically? I think Paste
> > Deploy provides at least good start on this.
> >
> > You haven't commented on the entry points defined by Past
On Saturday 03 March 2007 15:54:41 Ian Bicking wrote:
> Chad Whitacre wrote:
> > I suggest that a system with multiple simple config files is much
> > more scalable than a single complex config file syntax. Imagine
> > if all of Unix were configured using a single syntax!
>
> There's other cases wh
Joseph Tate wrote:
> On Saturday 03 March 2007 15:54:41 Ian Bicking wrote:
>> Chad Whitacre wrote:
>>> I suggest that a system with multiple simple config files is much
>>> more scalable than a single complex config file syntax. Imagine
>>> if all of Unix were configured using a single syntax!
>> T
At 10:02 AM 3/5/2007 -0500, Jim Fulton wrote:
>Entry points add *a* mechanism to make those objects a bit more
>discoverable. Arguably, specifying an application via:
>eggname#entrypointname doesn't provide much advantage over simply
>specifying the dotted path to an object in a module.
Actually,
On Monday 05 March 2007 16:19:14 Ian Bicking wrote:
> Joseph Tate wrote:
> > I find that multiple files gives you a nice way to override defaults. As
> > long as the files are read in a way that's predictable and documentable,
> > and ultimately appear as if read from a single file (and possible
>
On Monday 05 March 2007 16:38:51 Phillip J. Eby wrote:
> At 10:02 AM 3/5/2007 -0500, Jim Fulton wrote:
> >Entry points add *a* mechanism to make those objects a bit more
> >discoverable. Arguably, specifying an application via:
> >eggname#entrypointname doesn't provide much advantage over simply
>
At 09:46 PM 3/5/2007 -0500, Joseph Tate wrote:
>Those using $4.95 hosting plans are only setting up one server, and will need
>something custom to their installation anyway, so "pydeploy" won't help them
>either. They'll be trying to install trac, some blogging software and then
>an arbitrary imag
On Mar 5, 2007, at 4:38 PM, Phillip J. Eby wrote:
...
> Personally, I don't care for the Paste Deploy syntax -- frankly
> it's almost barbaric. :)
I don't mean to pick on you, but I really *hate* comments like this.
I don't like softer forms like "complicated" or even "makes me
uneasy".
On Mar 5, 2007, at 5:23 PM, Joseph Tate wrote:
> On Monday 05 March 2007 16:19:14 Ian Bicking wrote:
>> Joseph Tate wrote:
>>> I find that multiple files gives you a nice way to override
>>> defaults. As
>>> long as the files are read in a way that's predictable and
>>> documentable,
>>> and
On 3/7/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Aside from the universal configuration file issue, I think this would
> be a terrific thing for us to focus on. Something I hear a lot is
> how much easier PHP applications are to deploy to hosting providers.
> I would *love* it is Python had a si
On 3/7/07, James Bennett <[EMAIL PROTECTED]> wrote:
> On 3/7/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
> > Aside from the universal configuration file issue, I think this would
> > be a terrific thing for us to focus on. Something I hear a lot is
> > how much easier PHP applications are to deploy
On Wednesday 07 March 2007 05:34:15 Jim Fulton wrote:
> I'd love to get some input who know a lot about what makes deploying
> PHP apps so easy.
It's not the packaging format. Most php apps come down as a tarball. Extract
it to your apache root, and you can connect to the app and do configurati
Jim Fulton wrote:
>> A couple years back, I started writing a library to parse a more
>> sophisticated, Python-like syntax to do the same sorts of things,
>> but only got as far as the parser.
>
> A few years back, we created a library to parse more sophisticated
> apache-like syntax and I w
On 3/7/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
> On Mar 5, 2007, at 4:38 PM, Phillip J. Eby wrote:
> ...
> > Personally, I don't care for the Paste Deploy syntax -- frankly
> > it's almost barbaric. :)
>
> I don't mean to pick on you, but I really *hate* comments like this.
> I don't like soft
Jeff Shell wrote:
> Configuration and deployment?
>
> I'm trying to understand the scope of these terms (or this combined
> term) better. I take it 'configuration' means just how an 'app' might
> publish itself to a WSGI server. Is that right?
>
> For us, deployment now is:
>
> 1. Make a Zope 3
Jeff Shell wrote:
> But in theory, since Zope 3 has `zope.app.wsgi`, I could serve from...
> anything? I guess that since I don't think about serving via Twisted
> any more than I thought about serving via ZServer, I could put
> CherryPy, mod_wsgi, whatever else underneath, right?
In theory you ca
On 3/7/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Jeff Shell wrote:
> > Configuration and deployment?
> >
> > I'm trying to understand the scope of these terms (or this combined
> > term) better. I take it 'configuration' means just how an 'app' might
> > publish itself to a WSGI server. Is tha
Jeff Shell wrote:
> Often we have web apps, written in Zope 3, that are really two or more
> web apps. Like an 'admin' side and 'public' side, typically handled
> via different skins/views. Apache rewrite rules basically handle that
> routing. So in my mind, if I deploy our CMS, I have the followin
Jeff Shell wrote:
> On 3/7/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > Jeff Shell wrote:
> > > Configuration and deployment?
> > >
> > > I'm trying to understand the scope of these terms (or
> this combined
> > > term) better. I take it 'configuration' means just how an
> 'app' might
> > > p
James,
Thanks for weighing in.
>> I'd love to get some input who know a lot about what makes
>> deploying PHP apps so easy.
>
> In a past life I had a fair amount of experience working with
> and deploying PHP, so I'll throw in my $0.02.
>
> It's worth pointing out that a lot of the "PHP i
> Anyway, my feelings are that it's: (a) simple hierarchy through
> the filesystem (which will make Chad all excited ;)
BLAM!!!
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsu
On 3/7/07, Ian Bicking <[EMAIL PROTECTED]> wrote:
> In theory you can set up Zope 3 using something like:
>
>[app:main]
>paste.app_factory = some_function_yet_to_be_written
>
> I thought zope.paste did this, but it's a little wonky now that I look
> at it.
Well, you're probably missing som
Jim Fulton wrote:
> On Mar 5, 2007, at 4:38 PM, Phillip J. Eby wrote:
> ...
>> Personally, I don't care for the Paste Deploy syntax -- frankly
>> it's almost barbaric. :)
>
> I don't mean to pick on you, but I really *hate* comments like this.
That's okay ;-)
> criticism. I'd appreciate i
On 3/8/07, Chris Withers <[EMAIL PROTECTED]> wrote:
> I'm glad ZConfig exists.
Me too, though it does many things differently than if I'd had free reign.
> How does it handle nesting?
It doesn't, but an application can use explicit references to other
sections. It doesn't take care of things ma
On Mar 7, 2007, at 10:36 PM, Chad Whitacre wrote:
> James,
>
> Thanks for weighing in.
>
>>> I'd love to get some input who know a lot about what makes
>>> deploying PHP apps so easy.
>>
>> In a past life I had a fair amount of experience working with
>> and deploying PHP, so I'll throw in my $0.
On Mar 8, 2007, at 4:55 AM, Chris Withers wrote:
> Jim Fulton wrote:
>> On Mar 5, 2007, at 4:38 PM, Phillip J. Eby wrote:
>> ...
>>> Personally, I don't care for the Paste Deploy syntax -- frankly
>>> it's almost barbaric. :)
>> I don't mean to pick on you, but I really *hate* comments like t
Jim Fulton wrote:
>
>> It all gives indication. Yes, if only one person says "this sucks",
>> then their opinion may not be worth changing the implementation for.
>> However, if 50% of users said "this sucks", even if they couldn't
>> explain why, that'd be something worth worrying about.
>
>
41 matches
Mail list logo
