Re: more comments on Paste Deploy

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, it provides one very important strategic advantage
that I don't 
think has been mentioned in this conversation.  A
configuration format that 
can specify project/version information can be used as a
single-file 
deployment spec for an easy_install wrapper or buildout-like
tool.

The advantage of this for virtual hosting providers in
particular is 
significant -- if they support the tool, they can support
this one-file 
deployment scheme.

Personally, I don't care for the Paste Deploy syntax --
frankly it's almost 
barbaric.    But the
concept of being able to specify stacks, routes, and 
configuration in a plain text format that includes package
information for 
automated deployment is nonetheless an important one.

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.

One discussion was here:

http://mail.python.org/pipermail/web-sig/2005-Au
gust/001714.html

The basic idea behind the syntax was that assignments are
like keyword 
arguments, and non-assignment statements are positional
arguments.

I'm not altogether happy with that syntax either, however,
as it has a 
little too much "more than one way to do it",
which is one reason I never 
finished the implementation.  There is a library that parses
it (and does 
other general-purpose Python-like DSL parsing) at:

ViewSVN:   http://svn.eby-sarna.
com/SCALE/
Checkout:  svn://svn.eby-sarna.com/svnroot/SCALE/
Docs: 
http://peak.telecommunity.com/DevCenter/sc
ale.dsl#parsing-declarations

Anyway, all that aside, I think it would be fantastic if we
could come up 
with some "universal file format" for single-file
configuration and 
deployment of applications (including auto-install of all
needed eggs), 
that could get stdlib support and ultimately hosting company
support.  This 
would actually give us a leg up on even PHP for
ease-of-deployment.

In truth, it doesn't matter if the file *contents* are 
standardized.  Standardization could be as simple as
defining a #! line like:

#!/usr/bin/pydeploy2.3 SomeFormatEgg==1.1

Where "SomeFormatEgg" offers a
"python.deploy" entry point for running the 
file, and the pydeploy tool obtains the necessary egg and
provides 
libraries for the parsing tool to auto-locate and install
any eggs needed 
by the body.

This could also be a basis for bootstrapping other systems,
including 
perhaps buildouts (e.g. "#!/usr/bin/pydeploy2.4
zc.buildout" at the top of 
a buildout .ini)!

So, while a single content format would be nice, we don't
even need that in 
order to get a raw deployment system standard.  Perhaps I
should build this 
hypothetical pydeploy tool into setuptools 0.7?

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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
> >specifying the dotted path to an object in a
module.
>
> Actually, it provides one very important strategic
advantage that I don't
> think has been mentioned in this conversation.  A
configuration format that
> can specify project/version information can be used as
a single-file
> deployment spec for an easy_install wrapper or
buildout-like tool.
>
> The advantage of this for virtual hosting providers in
particular is
> significant -- if they support the tool, they can
support this one-file
> deployment scheme.
>
> Personally, I don't care for the Paste Deploy syntax --
frankly it's almost
> barbaric.    But the
concept of being able to specify stacks, routes, and
> configuration in a plain text format that includes
package information for
> automated deployment is nonetheless an important one.
>
> 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.
>
> One discussion was here:
>
> http://mail.python.org/pipermail/web-sig/2005-Au
gust/001714.html
>
> The basic idea behind the syntax was that assignments
are like keyword
> arguments, and non-assignment statements are positional
arguments.
>
> I'm not altogether happy with that syntax either,
however, as it has a
> little too much "more than one way to do it",
which is one reason I never
> finished the implementation.  There is a library that
parses it (and does
> other general-purpose Python-like DSL parsing) at:
>
> ViewSVN:   http://svn.eby-sarna.
com/SCALE/
> Checkout:  svn://svn.eby-sarna.com/svnroot/SCALE/
> Docs:
> http://peak.telecommunity.com/DevCenter/sc
ale.dsl#parsing-declarations
>
> Anyway, all that aside, I think it would be fantastic
if we could come up
> with some "universal file format" for
single-file configuration and
> deployment of applications (including auto-install of
all needed eggs),
> that could get stdlib support and ultimately hosting
company support.  This
> would actually give us a leg up on even PHP for
ease-of-deployment.

Doesn't setuptools already give this?  easy_install
foo.app.egg will install 
all of the needed eggs if the dependencies are properly
listed.

> So, while a single content format would be nice, we
don't even need that in
> order to get a raw deployment system standard.  Perhaps
I should build this
> hypothetical pydeploy tool into setuptools 0.7?

I don't see there being a lot of demand for this.  The use
case I'm 
considering is the end user developer or administrator
deploying one or more 
delivered pyhon web applications to a production environment
(self hosted, 
colo-hosted, or leased server).  I think that except for
where you have 
multiple servers behind a load balancer or something, this
is a one time 
operation (barring failure cases, etc).  Administrators
already script this 
kind of thing using shell.

Also, in any "enterprise" environment that I'm
familiar with, the 
automatically download and install software mechanism
wouldn't fly.   
Administrators want to know everything that goes on a
system, and want the 
software managed through their patch/package management
system.  
Philosophical discussions on whether that's good or not seem
to be 
irrelevant.

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 image gallery, et. al., but won't have the same
selections as 
another $4.95 hosting customer.  This is the key problem
we're trying to 
solve.

I consider the packaging and delivery problem solved[1], or
at least out of 
the scope of this problem.

-- 
Joseph Tate
Software Engineer
rPath Inc.
http://www.rpath.com/r
builder/
(919) 851-3984 x2106

[1] Good enough for most things but better support for stuff
outside the egg 
is needed: config files (so that the user can tweak them),
locale data 
(or maybe a pkg_resources wrapper for gettext that loads
that data from the 
egg).
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 image gallery, et. al., but won't have the
same selections as
>another $4.95 hosting customer.  This is the key problem
we're trying to
>solve.

I was saying that they would drop in a single file for trac,
a single file 
for a blog, one for an image gallery, etc.  That's a heck of
a big 
deployment advantage, actually.

I wasn't talking about configuring a "server" -- I
was talking about 
deploying *applications*.

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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".  It would be far more helpful if you provides
specific  
criticism.  I'd appreciate it if we would all just ignore
statements  
like this and, preferably, stop making them.

>   But the concept of being able to specify stacks,
routes, and  
> configuration in a plain text format that includes
package  
> information for automated deployment is nonetheless an
important one.

Yes

> 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 wish we hadn't.  The ini/config
format is  
pretty standard and, IMO, really quite adequate.  I'm
convinced that  
we don't really need another configuration format, at least
not at  
this level.

...

> Anyway, all that aside, I think it would be fantastic
if we could  
> come up with some "universal file format" for
single-file  
> configuration and deployment of applications (including
auto- 
> install of all needed eggs),

Me too. That's one of the reasons I created zc.buildout. 
But that's  
a big commitment.  With buildout, I can use a single
configuration  
file and have recipes that generate lots of little
configuration  
files as necessary, for lots of applications like databases,
ldap  
servers, and web applications that will never use a single 

configuration file on their own.  I'd be happy if we could
tackle a  
simple configuration format that handled the kinds of things
Paste  
Deployment handles now and maybe a little more.  I'll get my
cake and  
eat it too with buildout. 


> that could get stdlib support and ultimately hosting
company  
> support.  This would actually give us a leg up on even
PHP for ease- 
> of-deployment.

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 similar story, even if
only for  
smaller applications.

I'd love to get some input who know a lot about what makes
deploying  
PHP apps so easy.

Jim

--
Jim Fulton			mailto:jimzope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org



_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com