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
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 i
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
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 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 (ins
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 progra
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 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
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 (eg.)
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
som
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 thing
> 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
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
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 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 .
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 earl
> 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 H
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 (and
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
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 o
--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
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
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 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 /var/lib/
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 t
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 i
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 t
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 agre
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 pr
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 versioni
- 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?
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 soft
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 Wed, 2003-06-18 at 19:26, Adrian van den Dries wrote:
> 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.
To make matters clear, my concern about adhering to the FHS is limited
to offering features w
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 su
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 "/path/to/zope/ins
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 y
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/Startu
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
39 matches
Mail list logo
