Re: [Pyb-developer] RE: pyb collaboration

[Anthony E. <me...@an...>]

Andy Robinson wrote:

>Hi folks.  I just joined.  I am starting a campaign for
>'best practice standards in enterprise deployment' in Python,
>something my company needs badly, and one big item on my wish
>list is something like Ant.  There are several contenders
>but this looks like the simplest and cleanest so far...
>
>I'd like to ask a few questions about where pyb might go,
>subject to sufficient resources.  
>
>0. GPL: fine for now, but if Guido agreed to get it into
>the standard Python library one day (which is BSD/LGPL-like),
>would you accept?  (we can dream....)
>
>  
>
Let's cross that bridge when we get to it. ;-)  Up until recently all of
my open source projects have been released under an Apache-style license
with basically no restrictions.  However recent reflection and the
growing number of open source projects which are dual licensed and which
are effectively making a profit, has be questioning whether such
flexible licenses are a good thing.  Having said that if it was between
keeping GPL and being able to incorporate something into the Python
library I think the choice is fairly obvious. :-)

>1. Ant has a standard way to keep config info external to the
>build script (ftp servers, hosts, passwords); you can thus safely 
>check in build scripts and have a config file in each environment.
>Is this desirable?
>  
>
Yes.   However I would like to be able to have external properties
appear in the build script as variables, since that is the way
properties are currently implemented.  The benefit as I see it is the
ability to define data structures such as lists and maps in a much more
concise fashion than can be done with properties (as implemented in Ant).

>2. filesets as objects: 
>The copy task and friends seem to be just walking the tree under where 
>you start with include and exclude filters.  Is this just a
>starting point or do you feel it is the optimum solution?
>
>  
>
It's just a starting point.  It was the simplest solution to the problem
at hand and seems to work well.  It would be nice to be able to reuse
filesets though in certain cases.

>I have seen half a dozen classes like filesets in Ant, including one 
>buried in distutils, and everyone doing deployment stuff implements one.
>I'd like to see one as a standard Python library module one day.  I 
>also  implemented the 'superglob' (e.g. include "spam/**/*.py") which
>I find very nice expressive syntax, and can contribute this if
>desired.  
>  
>
I'd be happy to consider other options, as long as they stay true to the
original design goals of pyb which is: do the simplest thing to get the
job done.

>3. Python versus XML: should build scripts be Python forever, or 
>would a mapping from XML be useful later?  (I have a 50/50 split 
>with people I have talked to, I also tend to feel GUIs to build/edit 
>build scripts are good, if further off..)
>
>  
>
OK, here's my thought on this: if you want XML build scripts then you
can use pyant.  I personally don't want to go that direction.  If I can
convert my XML build scripts into Python scripts which are half the size
and more concise then I have accomplished one of my goals with pyb.  If
pyb were to use XML syntax then that would effectively negate the need
for the library at all.

>4. tasks as objects vs. tasks as functions.
>The latter is the way you have gone and Java has no functions :-)
>I wonder if the former would be more useful if you ever want to 
>(a) instantiate from xml (i.e. have enough metadata to know
>the type of arguments)
>(b) give them all a channel for logging stuff as they do
>their work
>(c) create generic GUI dialogs for building scripts
>(d) have some global context for tasks (e.g. to externally
>store and make available
>
>  
>
a.) Sure, but like I said that has already been done with pyant and
doing the same thing in pyb would defeat the purpose.
b.) That already exists, they just call a function in util.
c.) This could be done without XML - the structure of the Python scripts
is remarkably similar to XML just without the verbosity and with
flexibility to take advantage of the Python language.  A GUI for
building scripts could simply be a code generator.
d.) This can be done today, and in fact is through global variables.

I'm not ready to create a class explosion if it isn't absolutely
necessary.  The way I see it a task is just a function and thus can be
most cleanly implemented as such since Python supports that type of
programming.

>5. Scons (scons.sourceforge.net) is really
>moving ahead in the C/C++ domain.  It deals with different issues.  
>But key people in the python world who don't have experience of 
>enterprise server stuff have said and will say again "why are 
>you duplicating this"?  Any ideas how to define the difference?  
>Has anyone here looked at scons to see if the models could be 
>merged or share tasks?
>
>  
>
Scons seems to be approaching the problem from a different direction
than Ant (and pyb).  Now, I've not used Scons, I've only read the
documentation, so I may be way off base here and I hope someone will
correct me if I am.  So far my impression of Scons is that it tries to
hide a lot from the build script.  If you want to compile something you
essentially do Program('file') and it will magically do what it needs to
do, detecting tools, determing what language the file is, so on and so
forth.  Personally I don't like this type of magic.  I want to be able
to control what I am doing.  Additionally a lot of developers are
familiar with Ant, especially Java developers, and thus it seems like a
good model to work with to provide a crossover into Python.  I count
myself as one of those more familiar with Ant than Scons or Cons, and
thus the tool was designed as such.

>I have no strong feelings on any of the above, just want to
>get a sense of where you are heading..
>
>  
>
It's good to get this out early.  Additionally my feelings for this
could change over time.  But for the moment my goals are:

   Simplicity (in build scripts and implementation) and clarity in the
implementation (minimize the magic and limit class explosion).

Sincerely,
Anthony Eden