Re: [A-a-p-user] A-A-P advocacy request: building and releasing Zope

[Bram M. <Br...@mo...>]

Jean Jordaan wrote:

> During an extensive thread about the building and packaging scripts
> of Zope (starting at [1]), I made a call for the consideration of
> A-A-P (at [2]. Judging from the website, I'm pretty sure that A-A-P
> is a perfect fit for the job. However, I haven't used it yet myself,
> and some Zope developers are starting to ask questions that require
> experience to answer. Therefore, I'm now asking this list whether
> anyone feels like responding to Shane, below.
> 
> [1] http://mail.zope.org/pipermail/zope-dev/2003-June/019885.html
> [2] http://mail.zope.org/pipermail/zope-dev/2003-June/019934.html

A-A-P indeed has the goal to be able to do the job of building and
installing very well.  And most of it is working.  If there is something
that doesn't work yet, it should be relatively easy to add.  Either as a
generic feature in A-A-P or with some extra Python code specifically for
the job.

I don't know Zope, but I'll try to answer the questions anyway.

> Shane Hathaway wrote:
>  > Jean Jordaan wrote:
>  >
>  >>> It *sounds* like it's being suggested that we replace "make"
>  >>
>  >> That's correct, though Aap can usefully do much more than make,
>  >> such as fetching remote sources and managing CVS checkouts/-ins.
>  >
>  > This is the kind of thing I'm interested in.  I don't need a make
>  > replacement, I need a way to manage combinations of software.  I have
>  > the following essential use cases:
>  >
>  > 1. Zope Corp.'s customer needs to install 15-20 particular versions of
>  > software that ZC ships to them (including Python, Zope, ZRS, Zope
>  > products, Spread, and some scripts.)  The customer needs the process of
>  > installing to take a minimum of effort, therefore all packages should be
>  > bundled into a single archive and the whole build process should be
>  > automated.  Zope Corp. needs to be sure that the customer installs
>  > exactly the right versions of software.  Once the software is installed,
>  > the customer should be able to run some tests to verify correct
>  > installation.

This can be done with Aap.  You can either include the recipe with the
software (e.g., on a CD_ROM) or just distribute the recipe and have it
download the required software when it's to be installed (useful if the
software has to be downloaded anyway and some parts are optional).  Aap
can even install tools that are needed (mostly useful on MS-Windows).

>  > 2. When Zope Corp. ships a new version of the software to the customer,
>  > the process of upgrading should be as simple as the first installation.
>  >  The upgrade process should remove old files before installing new files.

This is possible, although it currently needs to be specified
explicitly.  I have been thinking of making this easier by including
support for installing packages, but that didn't happen yet.  Possibly
one of the existing systems can be used (maybe re-implemented in Python
to keep it portable).  The only disadvantage of doing this in an
Aap-specific way is that it needs to co-exist with whatever package
system is normally used on a system (each kind of OS tends to have a
different one...).

>  > I also have the following important, but not essential, use cases:
>  >
>  > 3. It should be possible to find out easily what software versions and
>  > CVS tags the customer is using.  Therefore, all software versions and
>  > CVS tags should be managed in a central place, ideally in a single,
>  > short file.

This should be possible with a few cvs commands and Python code to
filter the output.  But I don't see how this works together with the
"bundled into a single archive" that you mentioned above.  Are you using
CVS on the customers system or are you sending him a bundle of files?

>  > 4. It should be easy to build the software from scratch.  This primarily
>  > serves the needs of developers, but it also serves customers who want to
>  > build the software on their own systems rather than use binary packages.

Aap does software building very well.  You can convert your Makefiles to
Aap recipes, since recipes can do everything that Makefiles can.  But
you could also invoke "make" from the recipe if you want to (avoids
having to convert everything at once).

>  > 5. The software should be managed independently of the operating system.
>  >  The system might have a stock version of Python 2.1.2 installed, but my
>  > software requires Python 2.1.3 with large file support and a patch to
>  > distutils.

With "my software" do you mean the software that is being installed or
what is done during the build process?  It's also not clear to me what
"managing the software" means for you.

>  > So, does a-a-p or scons do those things?  (This might be too much to
>  > ask, but my little prototype software combination manager does almost
>  > all of these things.)

The main advantage you will have by using Aap is that it will do
everything that make does, plus take care of downloading and CVS access.
The Aap recipe will be much simpler than doing the same with a Python or
shell script.  If the built-in support of Aap is not enough, you can mix
in Python where needed.  That avoids using shell commands, which gets
messy quickly and is difficult to keep portable (but you can still use
shell commands where you want to).  Flexible, isn't it?

-- 
hundred-and-one symptoms of being an internet addict:
119. You are reading a book and look for the scroll bar to get to
     the next page.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///