On June 18, Chris McDonough wrote:
And Guido, for zdctl.
Will Zope use zdctl?
It would be cool to have the same framework used to control individual
instances (Zope or ZEO), and zopectl can become an external zdaemon
instance manager (I'll call it z*ctl). Zope and ZEO simply provide
start
On Friday 20 June 2003 01:19 am, Jean Jordaan wrote:
There's only one possible way! A-A-P! (A good match for Ape, Shane ;)
It's a replacement for make by Bram Moolenaar, the author of Vim, and
it looks like it does a lot of things Right.
Sorry, I haven't really been paying attention so
On Friday 20 June 2003 04:57 pm, PieterB wrote:
On Friday 20 June 2003 01:19 am, Jean Jordaan wrote:
There's only one possible way! A-A-P! (A good match for Ape, Shane ;)
It's a replacement for make by Bram Moolenaar, the author of Vim, and
it looks like it does a lot of things Right.
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.
Has anyone used SCons? http://www.scons.org/
Well, they feature neck-and-neck in July, so if someone (or
I think the default Zope install should not have dependencies other
than that Python is required and the user has some shell system
(bash/sh/MS batchfiles).
... and aap apparently ;)
I'm thinking that ZC needs a more capable make replacement. That
isn't quite the topic of this thread, but Aap
On Thu, Jun 19, 2003 at 10:59:29AM -0400, Chris McDonough wrote:
So, in any case, given that the ZC source tarball installer will not
attempt to manage multiple instances (we'll leave that to Luca) here are
the requirements I've gathered so far:
- Add a --doc flag to configure
- Add a
On Fri, Jun 20, 2003 at 03:38:53PM +1000, Adrian van den Dries wrote:
Well, as we all know, shell scripting kinda blows. There is no way that
I know of to portably use an array in shell, and I wanted to eventually
make it possible to use something other than bash to run the configure
On Fri, Jun 20, 2003 at 08:57:34AM +0200, PieterB wrote:
On the other hand some packages (such as my zopetest, or other
rpm-alike things), may require other things. I like A-A-P, because
I think that would make my installerfiles much cleaner. Aap has
integrated support to fail if a program
On Fri, 2003-06-20 at 01:38, Adrian van den Dries wrote:
You may be interested in Kenneth Almquist's ash (aka dash in Debian):
Optimally the configure script will work in any bourne-shell-derived
shell (e.g. the bourne shell on Solaris).
With the distutils, ``--home`` is version-agnostic
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
On Fri, 2003-06-20 at 02:10, Adrian van den Dries wrote:
On June 18, Chris McDonough wrote:
And Guido, for zdctl.
Will Zope use zdctl?
Zope does use zdctl. It's what gets invoked when you run zopectl. I
need to degeneralize the zdctl invoked by Zope a bit in order to support
zopectl debug
On Fri, 2003-06-20 at 03:55, Luca - De Whiskey's - De Vitis wrote:
Am I missing anything?
I'd like to have the possibility to install any architecture dependant files
in an different tree.
I'm afraid I'll need to understand more about what debian considers
architecture dependent. Can you
On Fri, Jun 20, 2003 at 10:58:54AM -0400, Chris McDonough wrote:
I'm afraid I'll need to understand more about what debian considers
architecture dependent. Can you provide details about what this
means?
[There is nothing special about Debian and architecture dependent files]
Dependent is
OK, thanks, I thought this was it. In Zope's case, this just implies
compiled Python libraries. This can normally be specified via the
--platlib flat to setup.py, but as described in a prior message in this
thread, the Zope setup.py overrides platlib in order to provide
X-platform compatibility
- Original Message -
From: Adrian van den Dries [EMAIL PROTECTED]
May I respectfully ask why there is so much concern with such
complicated setups? Surely a production environment (which is what
any Zope distribution should aim for) will standardise on a software
version?
I have
Chris wrote:
We have make-driven software that creates us a tree via a single command
by checking out various version of Python, Zope, etc. from CVS and
compiling and installing them. Different versions of Zope and Python,
etc. can be installed in opt and we use symlinks to manage versioning.
On June 19, PieterB wrote:
Could that make-driven software be made public? I'm currently trying to
create similar Makefiles (for a new FreeBSD zope port) and would be
interested in using ZC files.
This sort of stuff is almost definitely deployment-specific (and quite
likely ZC proprietary
On Thu, Jun 19, 2003 at 09:26:51AM +1000, Adrian van den Dries wrote:
Well, if you're going to have a policy shoot-out:
[...]
I think most of us would agree that .py(c) files are *libraries* and
not *data files*. Data files would be the skeleton instance
directory.
Of course i do not agree,
On Wed, Jun 18, 2003 at 03:08:12PM -0400, Chris McDonough wrote:
If you want to change your Zope controller to work with 2.7, I think
you'll either be very happy (or very disappointed, seeing how much work
you put in to creating your own config files) to know that Zope 2.7+
instances have
On Thu, 2003-06-19 at 02:57, PieterB wrote:
Chris wrote:
We have make-driven software that creates us a tree via a single command
by checking out various version of Python, Zope, etc. from CVS and
compiling and installing them. Different versions of Zope and Python,
etc. can be installed
On Thu, 2003-06-19 at 10:14, Chris McDonough wrote:
On Thu, 2003-06-19 at 02:57, PieterB wrote:
Chris wrote:
We have make-driven software that creates us a tree via a single command
by checking out various version of Python, Zope, etc. from CVS and
compiling and installing them.
On Wed, 2003-06-18 at 23:13, Adrian van den Dries wrote:
Distribution install - most common::
./configure.py --prefix=/usr \
--skel=/usr/share/zope/skel \
--doc=/usr/share/zope/doc
mkzopeinstance.py /var/lib/zope/default
ln -s
Chris McDonough wrote:
On Thu, 2003-06-19 at 10:14, Chris McDonough wrote:
On Thu, 2003-06-19 at 02:57, PieterB wrote:
How do those files compare to the buildscript:
http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org
The NZO make-driven buildout is an early revision of what
On Thu, 2003-06-19 at 09:53, Luca - De Whiskey's - De Vitis wrote:
On Wed, Jun 18, 2003 at 03:08:12PM -0400, Chris McDonough wrote:
I'm both disappointed and happy for the same reason :) When 2.7 will be out
i'll adapt my zopectl to the new Zope installation procedure.
Great.
I'll keep it a
--On Thursday, June 19, 2003 10:07:52 +1000 Adrian van den Dries
[EMAIL PROTECTED] wrote:
I'd advise against installing Zope library files into site-packages
unless you put them in a site-packages subdirectory (like
site-packages/zope270 or site-packages/zope271). Otherwise there will
be no
There's only one possible way! A-A-P! (A good match for Ape, Shane ;)
It's a replacement for make by Bram Moolenaar, the author of Vim, and
it looks like it does a lot of things Right.
http://www.a-a-p.org/index.html
In fact, Aap would fit very well with Gentoo. Gentoo's emerge system
takes care
On Thursday 19 June 2003 15:58, Shane Hathaway wrote:
Has anyone tried
extracting Gentoo's build system and using it for partial software
distributions? That might be the way to go.
I am now using Gentoo on all my servers and on this workstation.
I find value in being able to manage Zope
Jean Jordaan wrote:
There's only one possible way! A-A-P! (A good match for Ape, Shane ;)
It's a replacement for make by Bram Moolenaar, the author of Vim, and
it looks like it does a lot of things Right.
Interesting. A-A-P seems to have similar use cases. I should take a
serious look at it
http://www.a-a-p.org/index.html
This looks quite good! It has support python 2.2 support as well. I'll
see if I can play with it.
Pieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or
On June 19, Chris McDonough wrote:
On Wed, 2003-06-18 at 23:13, Adrian van den Dries wrote:
python2.1 configure.py --prefix=/opt/zope271-python21
(FWIW, configure is a shell script.)
Yes, I knew that. I used the .py extension for all the scripts to be
consistent, according to my earlier
On Thu, 2003-06-19 at 20:24, Adrian van den Dries wrote:
On June 19, Chris McDonough wrote:
On Wed, 2003-06-18 at 23:13, Adrian van den Dries wrote:
python2.1 configure.py --prefix=/opt/zope271-python21
(FWIW, configure is a shell script.)
Yes, I knew that. I used the .py
On Friday 20 June 2003 01:19 am, Jean Jordaan wrote:
There's only one possible way! A-A-P! (A good match for Ape, Shane ;)
It's a replacement for make by Bram Moolenaar, the author of Vim, and
it looks like it does a lot of things Right.
Sorry, I haven't really been paying attention so this
On June 19, Chris McDonough wrote:
On Thu, 2003-06-19 at 20:24, Adrian van den Dries wrote:
Why not avoid that altogether and let the user supply the
correct python?
This is somewhat of a style choice
OK, ZC's call. ;-)
Well, as we all know, shell scripting kinda blows. There is no way
On Wed, 2003-06-18 at 06:18, Adrian van den Dries wrote:
1. one --prefix is too limiting with this tree. You can't install
into an existing hierarchy like /usr, because of the zope-specific
directories import, skel and utilities.
Yes. Good point. I'd like to see us change the
On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote:
Actually the scripts in $INSTANCE/bin aren't shell wrappers for things
in $PREFIX/bin, they're shell wrappers for thing in
$PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers.
And so they would be copied for all
On Wed, 2003-06-18 at 13:18, Luca - De Whiskey's - De Vitis wrote:
On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote:
Actually the scripts in $INSTANCE/bin aren't shell wrappers for things
in $PREFIX/bin, they're shell wrappers for thing in
$PREFIX/lib/python/Zope/Startup.
Two points I neglected to mention earlier:
1. Many thanks to Chris McDonough (and his predecessors) for his work
so far, without which, this wouldn't have come up. ;-)
2. I see no reason for Zope to eschew the .py extension for callable
scripts, eg. configure.py, zopectl.py, etc.
On June 18, Luca - De Whiskey's - De Vitis wrote:
For what concern Debian, the intallation home will still be /usr/lib/zope
untill python fully comply FHS[1] (http://python.org/sf/588756). I'll probably
move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure.
Well, if
2. I see no reason for Zope to eschew the .py extension for callable
scripts, eg. configure.py, zopectl.py, etc. Distributions may
choose to wrap these in shell scripts, or strip the extension, but
that is a distribution's decision. $(insert impertinent aside
about Zope's
On June 18, Chris McDonough wrote:
These files needn't be here really. There are two scripts: zopectl and
runzope. They are convenience shell scripts that run zopectl.py or
runzope.py scripts that live in a software home after setting certain
envvars.
Whether you run
On Wed, 2003-06-18 at 20:07, Adrian van den Dries wrote:
Agreed; we can have a separate zopectl package that is dedicated to
managing instances.
I'm hopeful that Luca agrees.
I'd advise against installing Zope library files into site-packages
unless you put them in a site-packages
On Wed, 2003-06-18 at 18:48, Adrian van den Dries wrote:
Two points I neglected to mention earlier:
1. Many thanks to Chris McDonough (and his predecessors) for his work
so far, without which, this wouldn't have come up. ;-)
Thanks! But I can't take too much credit. You should probably
On June 18, Chris McDonough wrote:
(snip interesting insight into ZC's deployments)
This is doubtless the most common scenario (or it should be).
It is when things go right, but when they go wrong, it's fairly limiting
to only be able to have a single version of Zope installed on your
On June 19, Adrian van den Dries wrote:
Distribution install - most common::
...
Multiple pythons, zopes, instances - most complex::
Note that these aren't mutually exclusive: the porpoise of /usr/local
is to allow a site-local hierarchy. That is, the *system* only has
one version of the
44 matches
Mail list logo
