Re: [Zope-dev] 2.7 installation
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 hooks for zdaemon. So, you configure a ZEO instance and a Zope instance, add those instances to a global configuration file, and ask z*ctl to start the instances (if you have z*ctl) or you start them individually with zdctl.py. Hrm, applications that are really plugins to a generalised daemon application. That sounds familiar. ;-) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 might be completely OT. It *sounds* like it's being suggested that we replace make (given the above statement). Has anyone used SCons? http://www.scons.org/ Richard 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). 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 returns an error, which isn't the case for shell scripts. Make also has error support and can be used to define 'modules'/'tasks' but it's terrible to create something similar to http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org in Makefiles. I'm trying to create a product that would build Zope sandboxes with various products (CMF, Plone, Zwiki, etc). That's a different type of requirement than ZC building a production stable Zope. I think it's a basic seperation of concerns issue. The Zope install should facilitate users, and packagers to install a Zope instance. Other Zope installers/pacakers/etc. can do other things as they please. On the other hand: it would be nice if there is a standard-layout when people would like to build zope in-place. That would make it easier to document, and would make the life of sysadmin's running Zope on more than one platform much easier. About Scons: I never heard of it before, but it's not suitable for my task. I want to create something that can easily interact with FreeBSD ports, and what has Python2 support, and is more stable than 0.14 alpha which is written in Python 1.5.2 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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. Sorry, I haven't really been paying attention so this might be completely OT. It *sounds* like it's being suggested that we replace make (given the above statement). Has anyone used SCons? http://www.scons.org/ Richard 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 ;) About Scons: I never heard of it before It's been around for quite a while. It's based on the winning design for software construction tools (ie. make replacement) in the Software Carpentry contest (the website of which has vanished from the web now so you'll have to rely on the info at scons.org). It's certainly been around for longer than aap :) but it's not suitable for my task. I want to create something that can easily interact with FreeBSD ports Fair enough - as I mentioned, I haven't been paying close attention to the thread. My virtual ears pricked up when mention was made of replacing make ;) , and is more stable than 0.14 alpha I note with a grin that up until this month aap was at release 0.150 :) Richard pgp0.pgp Description: signature
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 someone someone knows) is around there, they could compare and ask pointed questions: 2003 May 15: BOF session at O'Reilly conference The proposal to organize a BOF session on A-A-P has been accepted. It will take place on Thursday evening July 10, from 8 to 9 pm. This is directly after the BOF session on SCons, in the same room. A nice occasion for people to talk about modern building tools! More information about the conference here. (links at http://www.a-a-p.org/index.html ) -- Jean Jordaan http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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.) would be cool already if it was just used by ZC to manage their checkout/builds, and was available as option for outsiders to use. The releases needn't have a new dependency. It's based on the winning design for software construction tools (ie. make replacement) in the Software Carpentry contest Yes, like Roundup :) It's certainly been around for longer than aap :) I'd bet that Bram has been brooding on Aap for a long time, and he certainly has masses of experience managing complex build environments, with Vim compiling on about a million architectures with or without myriads of compilation options, language bindings, GUI toolkits, etc. , and is more stable than 0.14 alpha I note with a grin that up until this month aap was at release 0.150 :) That's the hundred and fiftieth release, ne :) -- Jean Jordaan (using WindowMaker 0.80.2) http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 --skel flag to configure (is this a common pattern?) Possibly: - Make it possible to install Zope libraries into the site-packages directory of the Python that invokes Zope's setup.py instead of into software_home/lib/python. Am I missing anything? I'd like to have the possibility to install any architecture dependant files in an different tree. thanks, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 script (bash has arrays, but I'm not sure if bourne shell does). You may be interested in Kenneth Almquist's ash (aka dash in Debian): If you aim portability, I would suggest to use only standard tools: if you want to make an installation procedure portable trough various systems and architectures, you should only use strict sh scripting, Makefile and other tools which may be considered to be installed by default on any unix system. Speaking of Zope, python is also acceptable: you need python to run Zope, and so it is reasonable that you use a language that is supposed to be available on the target system. I would not use bash or any non standard sh derivation, because they might not be available. If you start to feel the need of some more complex constructs than those available with sh, than you should consider to use python. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 returns an error, which isn't the case for shell scripts. Try use #!/bin/sh -e instead of #!/bin/sh alone. Make also has error support and can be used to define 'modules'/'tasks' but it's terrible to create something similar to http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org in Makefiles. If you need i can port a script like that to Makefile without that much work. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 (installs package
``foo`` into ``$HOME/lib/python/foo/``) and ``--prefix`` is
version-aware (installs into ``$PREFIX/lib/pythonX.Y/site-packages``).
OK. This option always seemed a little weird to me, but let's run with
it. ;-)
``inst/Makefile.in`` could probably be updated to do a --prefix install
if $(PREFIX) is defined, else it defaults to a --home install.
(Mockups)
# the next commands are all equivalent
# and produce the install target
# ``python setup.py --home=/usr/local/zope``
python inst/configure.py --home=/usr/local/zope
./configure --home=/usr/local/zope
./configure
OK, looks good.
# the next command produces the install target
# ``python setup.py --prefix=/usr/local``
# which installs packages to /usr/local/lib/python2.2/site-packages
python inst/configure.py --prefix=/usr/local
I like it because it's consistent with the distutils flags.
Where do ancillary files like those in bin, doc, and whatnot go when you
invoke this command? /usr/local/bin and /usr/local/doc?
(Couple of hours later).
OK, attached is a patch to inst/Makefile.in and inst/configure.py that
distinguishes --home and --prefix parameters and passes them onto the
distutils. But for some reason, there is still no difference between
--prefix and --home, even though it's passing those options to the
distutils. I suspect it might have something to do with this exerpt
from setup.py::
Thanks for the work! I also like the structured text style colons! ;-)
# We create a custom install scheme that works the same way on all
# platforms. We do this in order to prevent distutils from trying to
# guess where to put our files on a per-platform basis.
ZOPE_INSTALL_SCHEME = {
'purelib': '$base/lib/python',
'platlib': '$base/lib/python',
'headers': '$base/lib/python',
'scripts': '$base/bin',
'data' : '$base/lib/python',
}
That looks a little evil to me.
Evil? That's a hundred dollar line of code right there! ;-)
Convincing distutils to behave in a predictable way is hard.
Distutils works very differently on Windows and UNIX. --home is not
supported on Windows and the default filepaths are different for a
prefix install between platforms. I have also experienced differences
in distutils behavior between Python versions that make it difficult to
know exactly what's going to happen when you run setup.py install. I
don't remember the details, but it wasn't pretty.
The ZOPE_INSTALL_SCHEME was meant to gloss over the differences in OS
and Python version. In this scheme, everything (data, scripts,
libraries) will always be installed into a single directory regardless
of your platform.
If we're no longer going to punt in this way, someone (probably me)
needs to do the work to ensure that we have all the options we need but
that it continues to work both under UNIX and Windows. Your code is a
start, but obviously we'll need to do some work on setup.py.
Thanks!
- C
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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. 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. 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. 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. 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. 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.) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.7 installation
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 and zopectl test but it will be largely the same (probably a subclass). 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 hooks for zdaemon. So, you configure a ZEO instance and a Zope instance, add those instances to a global configuration file, and ask z*ctl to start the instances (if you have z*ctl) or you start them individually with zdctl.py. Sounds like a fun project... - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 provide details about what this means? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 any file which cannot be used on a different hardware architecture. Compiled 'c' code is architecture dependent. Python compiled source (.pyc, .pyo), text files of any sort and almost all kinds of data files like sounds, images or videos do behave the same, regardless the hardware architecture they are installed on: thus they are architecture independent. I tryed any conbination of setup.py options to make it work, but i was not succesful: that led me to think this feature was not considered. thanks, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 for install locations. This is the thing that will need to change. Thanks! - C On Fri, 2003-06-20 at 12:19, Luca - De Whiskey's - De Vitis wrote: 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 any file which cannot be used on a different hardware architecture. Compiled 'c' code is architecture dependent. Python compiled source (.pyc, .pyo), text files of any sort and almost all kinds of data files like sounds, images or videos do behave the same, regardless the hardware architecture they are installed on: thus they are architecture independent. I tryed any conbination of setup.py options to make it work, but i was not succesful: that led me to think this feature was not considered. thanks, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
- 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 this need - and what we do is *exactly* what you ask: we standardise on a software version, on service level. It seems (my impression) that most unix distros take the following view: one service, one machine. We often find that we need to run several versions of both Zope and Apache on the same machine at the same time; this might be because the current production version of a service needs to have some packages for apache/zope that conflict with newer versions of apache/zope, or simply because we do not want to change the environment for production services that work. I have created a buch of shell scripts that allows me to handle several versions of python and Zope on the same machine, as well as manage several INSTANCE_HOMEs. Each INSTANCE_HOME can specify which python to use, which zope to use and any extra stuff that is needed (like what Oracle envrionment it wants to run with, etc). I will have/have had to change these for both Zope 2.6 and for Zope 2.7 - but my hope is that with 2.7 I can just throw my scripts away and use the stock ones. If the concern is because *developers* want to run multiple Zope instances on multiple Zope versions with multiple Python versions, then I would suggest writing an *alternative* mechanism for developers to mangle their PYTHONPATHs and whatever. I find that solutions for production environments, in the style of the one oulined above, work very well for development environments as well. My 2 öre worth... /dario - Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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. 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. How do those files compare to the buildscript: http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org PieterB ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 property - that is much of their revenue!) How do those files compare to the buildscript: http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org Jeebers, someone sure has an aversion to shell functions! ;-) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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, and your vision of those documents is quite erroneous, but this is an off-topic issue so i won't discusse it here. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 their own configuration file which has a syntax patterned after an Apache configuration file; the parsing system uses the ZConfig package (http://www.zope.org/Members/fdrake/zconfig/). I have attached the zope.conf.in file that represents a valid Zope instance configuration file. 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. As an upshot, z2.py no longer exists and the zopectl that runs Zope [...] That's not big deal: I'll manage instance operation trough instance specific zopectl script. I'd love to see your zopectl system work with Zope 2.7, and though I [...] If you want it to support Zope 2.7, I'd be happy to answer any questions about the new installation/startup process. I'll keep it a separate package, and i surely take advantage of your help. In particular, I think you'd need to change your zopectl conf file. [...] I'll most probably do in this way. Support for installing docs to a specific directory is no big deal. I'll add it to the Zope 2.7 TODO. Sounds cool. 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). I'll keep this in mind. If you can provide specific direction on how to make the Zope source tarball installer service your goals better, I'll be happy to try to implement any suggestions given that it makes sense in the larger cross-platform context. I'll mail you privately for this. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 in opt and we use symlinks to manage versioning. 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. 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 we use. There is no publically available later revision, but it hasn't changed all that much. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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. Different versions of Zope and Python, etc. can be installed in opt and we use symlinks to manage versioning. 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. 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 we use. There is no publically available later revision, but it hasn't changed all that much. Scratch that! I hadn't looked at it in a while. This looks nothing whatsoever like what our Makefile-driven buildout for NZO used to look like. I guess Sidnei didn't like it and changed it to a shell-driven buildout. The old version should be floating around somewhere... ah, there is is: http://cvs.zope.org/SiteLayout/?cvsroot=Zope.org. - C HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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/zope/default/etc /etc/zope/default echo -e '[default]\n/var/lib/zope/default' /etc/zopectl.conf I think you are suggesting that all Zope config files be put into /etc/zope with a master zope config file at /etc/zopectl.conf. If so, I think this might make a lot of sense for a managed-binary Zope multi-instance controller, but this is more a function of Luca's framework than the Zope source installer. I consider my job done after someone runs mkzopeinstance. zopectl.py start default All the above is invoked by ``apt-get install zope``, and the package can use a /etc/init.d/zope to loop through all instances. This looks like it's a function of Luca's 'zopectl'; not ZC's, but given that it sounds reasonable to me. Multiple pythons, zopes, instances - most complex:: cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 (FWIW, configure is a shell script.) # ... python2.1 configure.py clean python2.2 configure.py --prefix=/opt/zope271-python22 # ... cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 # ... python2.2 configure.py clean python2.2 configure.py --prefix=/opt/zope272-python22 Then you permute these with: python2.1 /opt/zope271-python21/bin/mkzopeinstance.py \ /var/zope/zope271-python21-instance1 python2.2 /opt/zope271-python22/bin/mkzopeinstance.py \ /var/zope/zope271-python22-instance1 # etc. And you have an installation with all permutations of multiple Pythons, multiple Zopes and multiple instances. Are you implying that the stuff that currently goes into software_home/lib/python would be installed to the site-package directory of the Python that was used to invoke the installer? If so, the subsequent invocations above of: cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 make; make install cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 make; make install ... would cause the Zope 2.7.1 libraries to be stomped by the Zope 2.7.2 libraries. Does this alleviate your concerns? ;-) If you mean that the libraries are installed into /opt/zope27X-python21/lib/python, there's no problem and nothing about the installer needs to be changed. 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 --skel flag to configure (is this a common pattern?) Possibly: - Make it possible to install Zope libraries into the site-packages directory of the Python that invokes Zope's setup.py instead of into software_home/lib/python. Am I missing anything? - C a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 we use. There is no publically available later revision, but it hasn't changed all that much. Scratch that! I hadn't looked at it in a while. This looks nothing whatsoever like what our Makefile-driven buildout for NZO used to look like. I guess Sidnei didn't like it and changed it to a shell-driven buildout. I don't blame him. Makefiles are very obtuse--especially if you try to make them modular and reusable! FWIW, I've put together a tool for managing rollouts of many software packages at once and I'm using it quite successfully for a customer project. I'd really like to either: - Release it as open source so others can use it and help maintain it. - Replace it with something with at least the same simple UI with its functionality, maintainability, and freedom. I prefer the second option, but I've had trouble finding anything that does the right things with a simple command-line UI. RedHat's RPM doesn't do enough. Debian's apt has a nasty UI and is tied too closely with Debian. Mandrake's urpmi, equivalent to apt, is tied too closely with Mandrake. There are various commercial tools, but I despise the possibility of legal issues. Just last night, though, I noticed that Gentoo is making a Mac OS X port. Not a PowerPC port, mind you, but a port to a different OS. That means Gentoo, like Debian, is not tied directly with Linux. And Gentoo's build system is written in Python, AFAIK. Has anyone tried extracting Gentoo's build system and using it for partial software distributions? That might be the way to go. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 separate package, and i surely take advantage of your help. Excellent. Thanks again, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
--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 way to run multiple Zope versions on the same machine sanely because different Zope versions have different libraries. 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? One word: migration As I've found out the hard way, there are times when it is much easier to conduct server upgrades if you can have different versions of Zope installed on a server at the same time. This is especially true in budget constrained colocation environments where adding additional machine for the upgrade would cost money. Dan Pierson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 of package metadata, fetching the source, and unpacking it. Once it's unpacked, it gets compiled, usually with the standard .configure; make; make install steps. Individual packages could use aap instead of make. Actually, Aap also takes care of the fetching phase. Then Gentoo installs the compiled package, keeping track of what files went where, so that they can be uninstalled, and queried for what package they belong to. This Aap doesn't do, AFAIK. -- Jean Jordaan http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 stuff as a non-root user. Portage was designed to allow this, but I doubt it is well exercised. Trying this has been on my to-do list for a while. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 at Gentoo.) I hope it's not too closely tied with Vim, though... ;-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 point to this end. It too is just a shell wrapper to find the correct python and palm off the remaining options to inst/configure.py. Why not avoid that altogether and let the user supply the correct python? Ie, instead of:: ./configure --with-python=/usr/bin/python3.2 --other --options you call:: /usr/bin/python3.2 configure.py --other --options Which it pretty much does, anyway. I also see things like this: # Up to six acceptable python versions are allowed. Why six? Where is it enforced? Are you implying that the stuff that currently goes into software_home/lib/python would be installed to the site-package directory of the Python that was used to invoke the installer? If so, the subsequent invocations above of: No, I'm saying that the systems should be allowed (or even encouraged) to do this. We already have sys.path and namespaces. In a 1:1 python:zope environment, this should be enough to identify the Zope packages. Hence installing into python's module path. For multiple-version environments, you need --home (see below). cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 make; make install cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 make; make install ... would cause the Zope 2.7.1 libraries to be stomped by the Zope 2.7.2 libraries. No, because --prefix just told configure.py to install *everything* in that location. If you want to alias this option to --home, that would probably make this clearer, but I don't think it's different in function. If you mean that the libraries are installed into /opt/zope27X-python21/lib/python, there's no problem and nothing about the installer needs to be changed. Aye. So, in any case, given that the ZC source tarball installer will not attempt to manage multiple instances (we'll leave that to Luca) Aye. here are the requirements I've gathered so far: - Add a --doc flag to configure - Add a --skel flag to configure (is this a common pattern?) I think so. But consider using the Make variables suggested earlier, so that distributions may customise the make step: ./configure --options --supplied --by --zope make SITE=local SPECIFIC=options - Make it possible to install Zope libraries into the site-packages directory of the Python that invokes Zope's setup.py instead of into software_home/lib/python. As long as each of the top-level Zope directories in the --home (bin, doc, lib, skel) can be individually tweaked, either in the configure.py or the makefile, I think we win both ways. Am I missing anything? Apart from my personal desire to see the shell scripts deprecated, nope. ;-) I think that's covered everything that concerns Zope itself, and the rest gets palmed off to zopectl and packagers. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 extension for all the scripts to be consistent, according to my earlier point to this end. It too is just a shell wrapper to find the correct python and palm off the remaining options to inst/configure.py. Why not avoid that altogether and let the user supply the correct python? This is somewhat of a style choice, but many people who come to Zope don't know much about Python. It is friendlier (imho) to inform them they need to install a particular Python version (and where to get it) to get Zope running after they invoke 'configure' without a Python around rather than force them to read docs ahead of time to understand this. But there is no need to use the shell wrapper. It's purely a convenience for this kind of user. Power users can use inst/configure.py directly if they so choose. But I'm not going to document it because if they're smart enough to know Python, they're probably smart enough to know they can invoke it this way by reading the shell script (as you were). Ie, instead of:: ./configure --with-python=/usr/bin/python3.2 --other --options you call:: /usr/bin/python3.2 configure.py --other --options Which it pretty much does, anyway. Right. I also see things like this: # Up to six acceptable python versions are allowed. Why six? Where is it enforced? 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 script (bash has arrays, but I'm not sure if bourne shell does). So, in any case, to get around this limitation, we have $FOUND1 - $FOUND6 variables which keep the result of the search for acceptable Python versions. It's enforced by the use of these variables. Were we to want more, we'd just create a $FOUND7 and so on. It probably could be made better, but I'd encourage you to just not look at this if it bothers you and use the inst/configure.py script directly. The shell script isn't particularly pretty, good, or elegant, but it serves its purpose. Are you implying that the stuff that currently goes into software_home/lib/python would be installed to the site-package directory of the Python that was used to invoke the installer? If so, the subsequent invocations above of: No, I'm saying that the systems should be allowed (or even encouraged) to do this. I agree they should be allowed. We already have sys.path and namespaces. In a 1:1 python:zope environment, this should be enough to identify the Zope packages. Hence installing into python's module path. For multiple-version environments, you need --home (see below). cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 make; make install cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 make; make install ... would cause the Zope 2.7.1 libraries to be stomped by the Zope 2.7.2 libraries. No, because --prefix just told configure.py to install *everything* in that location. If you want to alias this option to --home, that would probably make this clearer, but I don't think it's different in function. I think I understand at least half of that. Let me see if I can restate it. You're suggesting that --prefix be changed to --home. You're suggesting that specifying a --home implies that libraries will be installed to $home/lib/python. This is where I get a little confused. How does a user signify that Zope libraries should get installed into the Python site-package directory? What happens if --home is left unspecified? Is the --prefix option still around? If so, what does it do? Can you give an example of a configure command that would imply that Zope libraries get installed to site-packages? here are the requirements I've gathered so far: - Add a --doc flag to configure - Add a --skel flag to configure (is this a common pattern?) I think so. But consider using the Make variables suggested earlier, so that distributions may customise the make step: ./configure --options --supplied --by --zope make SITE=local SPECIFIC=options I think it is possible to tweak many things now via make -e after examination of the makefile. - Make it possible to install Zope libraries into the site-packages directory of the Python that invokes Zope's setup.py instead of into software_home/lib/python. As long as each of the top-level Zope directories in the --home (bin, doc, lib, skel) can be individually tweaked, either in the configure.py or the makefile, I think we win both ways. Great. Am I missing anything? Apart from my
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 might be completely OT. It *sounds* like it's being suggested that we replace make (given the above statement). Has anyone used SCons? http://www.scons.org/ Richard pgp0.pgp Description: signature
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 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
script (bash has arrays, but I'm not sure if bourne shell does).
You may be interested in Kenneth Almquist's ash (aka dash in Debian):
Description: The Debian Almquist Shell
dash is a POSIX compliant shell that is much smaller than bash.
We take advantage of that by making it the shell on the installation
root floppy, where space is at a premium.
.
It can be usefully installed as /bin/sh (because it executes scripts
somewhat faster than bash), or as the default shell either of root
or of a second user with a userid of 0 (because it depends on fewer
libraries, and is therefore less likely to be affected by an upgrade
problem or a disk failure). It is also useful for checking that a
script uses only POSIX syntax.
You're suggesting that --prefix be changed to --home.
...
You're suggesting that specifying a --home implies that libraries will
be installed to $home/lib/python.
This is where I get a little confused. How does a user signify that
Zope libraries should get installed into the Python site-package
directory? What happens if --home is left unspecified? Is the
--prefix option still around? If so, what does it do? Can you give
an example of a configure command that would imply that Zope libraries
get installed to site-packages?
Erm, yes. I originally wanted --home and --prefix aliased, but I've
changed my mind. It should mirror the behaviour of the same options
to the distutils' install target.
With the distutils, ``--home`` is version-agnostic (installs package
``foo`` into ``$HOME/lib/python/foo/``) and ``--prefix`` is
version-aware (installs into ``$PREFIX/lib/pythonX.Y/site-packages``).
``inst/Makefile.in`` could probably be updated to do a --prefix install
if $(PREFIX) is defined, else it defaults to a --home install.
(Mockups)
# the next commands are all equivalent
# and produce the install target
# ``python setup.py --home=/usr/local/zope``
python inst/configure.py --home=/usr/local/zope
./configure --home=/usr/local/zope
./configure
# the next command produces the install target
# ``python setup.py --prefix=/usr/local``
# which installs packages to /usr/local/lib/python2.2/site-packages
python inst/configure.py --prefix=/usr/local
I think it is possible to tweak many things now via make -e after
examination of the makefile.
OK, that is what the Deb should do.
Well, if you ignore the shell scripts, I think we're ok, then!
Peaches!
...
(Couple of hours later).
OK, attached is a patch to inst/Makefile.in and inst/configure.py that
distinguishes --home and --prefix parameters and passes them onto the
distutils. But for some reason, there is still no difference between
--prefix and --home, even though it's passing those options to the
distutils. I suspect it might have something to do with this exerpt
from setup.py::
# We create a custom install scheme that works the same way on all
# platforms. We do this in order to prevent distutils from trying to
# guess where to put our files on a per-platform basis.
ZOPE_INSTALL_SCHEME = {
'purelib': '$base/lib/python',
'platlib': '$base/lib/python',
'headers': '$base/lib/python',
'scripts': '$base/bin',
'data' : '$base/lib/python',
}
That looks a little evil to me.
a.
--
Adrian van den Dries [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
Index: doc/INSTALL.txt
===
RCS file: /var/lib/cvs/flowcom/Zope/dist/doc/INSTALL.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 INSTALL.txt
--- doc/INSTALL.txt 18 Jun 2003 02:27:46 - 1.1.1.1
+++ doc/INSTALL.txt 20 Jun 2003 05:03:29 -
@@ -13,7 +13,7 @@
Recommendations
- - You are recommended to build and install Zope as a non-root user.
+ - We recommend you build and install Zope as a non-root user.
Building Zope
@@ -23,8 +23,25 @@
./configure --prefix=/where/to/install/zope
make
- If you do not specify a '--prefix' option, during a later step, Zope
- will be installed into a default location.
+ or
+
+./configure --home=/where/to/install/zope
+make
+
+ If you do not specify the '--home' or '--prefix' options, during a
+ later step, Zope will be installed into a default location.
+
+ --prefix differs from --home by installing Python packages into
+ $PREFIX/lib/pythonX.Y/site-packages, where --home installs the
+ packages
[Zope-dev] 2.7 installation
My company has a business need for better Debian packages of Zope (and particularly, packages of ZEO). I have outlined a proposal for an installation regime that will greatly simplify installation in a UNIX environment, with a configuration that Debian would use for installation. I bring it up here because my proposal probably requires some changes to the source tree which may suit being accepted upstream, and because we have a (sponsored) opportunity to hone Zope for a Debian environment (a not uncommon and very high-quality distrubution). I am, however, not yet familiar enough with the distutils to know if this regime is possible, nor am I familiar with the Windows installation. Also, it pushes my relentless agenda to get the standalone packages of Zope packaged as separate dependencies which may, I sense, not suit everyone! ;-) It is at http://homepages.flow.com.au/~avdd/zope-newinstall.html and included here. Comments? Cc'ed current Debian maintainers for completeness. === Zope installation overhaul proposal === The Problem +++ I have some concerns about the new installation mechanism, particularly how it will work for a UNIX (specifically Debian) install. Currently, a configure script (written in Python) writes a makefile, which installs software into the --prefix, as per custom:: $ ./configure --prefix=$PREFIX $ make $ sudo make install This installs the software under ``$PREFIX``, producing this layout:: $PREFIX/ bin/ doc/ import/ lib/ skel/ utilities/ You then make an instance:: $ /usr/lib/zope/bin/mkzopeinstance $INSTANCE This creates a Zope instance in $INSTANCE, like so:: $INSTANCE/ Extensions/ Products/ bin/ etc/ import/ log/ var/ The problems with this procedure are: 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. 2. $INSTANCE/bin/* are just shell wrappers for their respective scripts in $PREFIX/bin, serving only to point to the correct configuration and software paths, also requiring you to supply a full path to the script. This should instead be a global control script that takes an instance name as an argument: # zopectl -i default start 3. This installs all of Zope, ZODB, ZEO and zdaemon. I am uncomfortable with this blurring of function between applications (runzeo.py) and libraries (ZODB) ... probably more ... skip to solution: The Solution For Zope The make install step:: EXECPREFIX=$PREFIX LIBPREFIX=$PREFIX SKELPREFIX=$PREFIX DOCPREFIX=$PREFIX BIN=$EXECPREFIX/bin LIB=$LIBPREFIX/lib # python, etc. DOC=$DOCPREFIX/doc SKEL=$SKELPREFIX/skel With ``PREFIX=/zope``, you get:: /zope/bin/ zopectl.py runzope.py utils.py etc. /zope/doc/ import/ Examples.zexp README.txt etc. /zope/lib/ python, etc /zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ Then the administrator (or initial installation) runs:: # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default which copies ``$SKEL/*`` to ``/var/lib/zope/default``. To start, stop, restart zope:: # zopectl default (start|stop|status|restart|etc) Other Z* packages = Note that the above procedure installs only Zope. It requires ZODB (a standalone package) to be installed. ZEO is a separate package. It installs similarly to Zope, with instances similarly created with ``$PREFIX/bin/mkzeoinstance``. This may require some changes to the source tree. The Debian package == Debian's package would use:: PREFIX=/usr SKEL=$PREFIX/share/zope/skel DOC=$PREFIX/share/doc/zope Producing this layout:: /usr/bin/ zopectl.py runzope.py utils.py etc. /usr/share/doc/zope/ import/ Examples.zexp README.txt etc. /usr/lib/ python, etc /usr/share/zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ The Debian installation would create a default instance, possibly prompting for the name (otherwise default). It would also create: - ``/etc/init.d/zope`` (starts the first instance, or all instances) - ``/etc/default/zope`` (lists instances) Debian's ``mkzopeinstance`` would symlink ``/etc/zope/$INSTANCE`` to ``/var/lib/zope/$INSTANCE/etc`` (like postgresql), and it may
Re: [Zope-dev] 2.7 installation
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 directory structure around so that installation into an existing prefix would be possible. This would imply getting rid of import, skel, and utilities and might mean (as per your suggestion) allowing more specific prefix targets for docs, lib, exec, etc. This is a bit of work, but would be possible. The setup.py script would need to be pretty smart. However, if we end up keeping it the way it currently is, the --prefix option should really be named --home so as to prevent any misunderstanding. 2. $INSTANCE/bin/* are just shell wrappers for their respective scripts in $PREFIX/bin, serving only to point to the correct configuration and software paths, also requiring you to supply a full path to the script. This should instead be a global control script that takes an instance name as an argument: # zopectl -i default start 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. If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? FWIW, I'd be very opposed to any sort of limitations on where instance homes could be placed to service this global control script's need to find instances. If you have only one Zope instance on your machine, you can link the zopectl script to /usr/bin/zopectl and get the convenience of typing 'zopectl' to do what you mention instead of '/path/to/zopectl'. If you have more than one Zope instance on your machine, I think they should be controlled by separate scripts instead of requring a framework to manage multiple instances on the same machine through some sort of path identification or config file listing all instances on the machine. See my comment in http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration dated Aug 22, 2002 8:09 pm for more background. 3. This installs all of Zope, ZODB, ZEO and zdaemon. I am uncomfortable with this blurring of function between applications (runzeo.py) and libraries (ZODB) OK. For Zope The make install step:: EXECPREFIX=$PREFIX LIBPREFIX=$PREFIX SKELPREFIX=$PREFIX DOCPREFIX=$PREFIX BIN=$EXECPREFIX/bin LIB=$LIBPREFIX/lib # python, etc. DOC=$DOCPREFIX/doc SKEL=$SKELPREFIX/skel With ``PREFIX=/zope``, you get:: /zope/bin/ zopectl.py runzope.py utils.py etc. /zope/doc/ import/ Examples.zexp README.txt etc. /zope/lib/ python, etc /zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could just move the skel directory into the lib directory and consider it part of Zope's libraries. Also, currently the scripts in $PREFIX/bin rely on being in a directory which peers with the lib directory. This would need to change were we to be able to specify an execprefix. Additionally, a particular execprefix would need to depend on the existence of a particular libprefix (the scripts in bin rely on being able to import stuff from libraries in the lib directory). This is why they're currently not broken apart. Then the administrator (or initial installation) runs:: # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default which copies ``$SKEL/*`` to ``/var/lib/zope/default``. What does -l do? To start, stop, restart zope:: # zopectl default (start|stop|status|restart|etc) Other Z* packages = Note that the above procedure installs only Zope. It requires ZODB (a standalone package) to be installed. It is not desirable to make people configure and install ZODB separately if they install from a tarball source distro. With package-managed distributions (especially apt which has very nice automated dependency management), this isn't such a big deal, but we want to make it easy to install a running Zope from source using with maximum complexity of './configure; make; make install'. That said, I agree in sentiment. If you want to change the setup.py script for Zope to do the right thing so it invokes ZODB's setup.py and the outcome is the same, I'd have no problem with that. Ditto for ZEO. Debian packages ZEO and the ZODB similarly, and ZEO and Zope depend on the ZODB. In the past, my offers to provide upstream support for Debian packaging hasn't been met with much enthusiasm. If I can make it easier for people to package
FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 instance installed: they would not probably be that large, but what about symbolik links? If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? I was not aware of a zopectl in the repository so i builded one in python for Debian. As i can see it's quite more powerful than the one you are going to include: http://packages.debian.org/unstable/admin/zopectl.html I would care about any comment. FWIW, I'd be very opposed to any sort of limitations on where instance homes could be placed to service this global control script's need to find instances. [...] http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration dated Aug 22, 2002 8:09 pm for more background. It's my opinion that a zope instance can be described trough a configuration file, thus not requiring multiple commands or links but rather a single command capable of using multiple configuration files. If you combine my zopectl script with the patch is proposed for z2.py (http://collector.zope.org/Zope/925), you'll have a good FHS[1] compliant framework for multiple INSTANCE_HOMEs (being still able to place any file where you like). This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could [...] libraries in the lib directory). This is why they're currently not broken apart. To say it all there is only one thing i really need: a way to install _all_ documentation files under a separate directory in a way thay cannot overlap. 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. In the past, my offers to provide upstream support for Debian packaging hasn't been met with much enthusiasm. If I can make it easier for people to package Zope for Debian, I'd love to, but I'd need to have some buyin and support from the current Debian packagers. Otherwise, it ends up being a waste of time on both of our parts as it won't be what's best for either of us. It's not that easy to co-maintain the Debian package for Zope: we actually lacks the structures to set up work with non Debian Developers. I suppose this problem will be solved soon, but if you like i can start collecting patches for the CVS repository i've already set up for that purpose. Take a look at https://alioth.debian.org/projects/pkg-zope and its CVS repository. Debian's packaging and installation strategy for Zope has always been very customized and divergent from the Zope source distribution's packaging and installation strategy. At very worst, it could stay this way. Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy. Not complying to Debian Policy is considered a grave bug for any package in the distribution. Current Zope upstream package is not that compliant, so we always have to modify the package. I hope this will change in future. ciao, [1] http://www.pathname.com/fhs/ -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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. But yes, they are shell wrappers. And so they would be copied for all instance installed: they would not probably be that large, but what about symbolik links? 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. Each of these shell scripts identifies a unique combination of software home, instance home, config file path, and pythonpath. These can be unique per instance, so using a symlink to a common set of files will not work. A typical zopectl script could be replaced with the following command line: ZOPE_HOME=/opt/Zope27 \ INSTANCE_HOME=/usr/local/zope/instance1 \ PYTHONPATH=/opt/Zope27/lib/python \ /usr/bin/python2.2 \ /opt/Zope27/lib/python/Zope/startup/zopectl.py \ -C /usr/local/zope/instance1/etc/zope.conf The -C tells where the Zope config file is. The config file represents settings for a single Zope instance. One of these config files is created for each Zope instance via 'mkzopeinstance'. If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? I was not aware of a zopectl in the repository so i builded one in python for Debian. As i can see it's quite more powerful than the one you are going to include: http://packages.debian.org/unstable/admin/zopectl.html I would care about any comment. I think this is great. The zopectl that ships with Zope now is capable of controlling a single Zope instance. Your system takes on the larger burden of simultaneous multi-instance Zope configuration and control on a single machine. Your code looks quite nice as well. Your system is a perfect example of a value-added frontend for zope. I can see that many people would want to use this kind of framework. I'd love to see people come up with their own Zope mgmt frameworks and use them as a frontend for Zope instance management with minimal involvement from the Zope source tarball installer. Different frameworks will be more or less valuable on different platforms; for example a Windows multi-instance controller might be a GUI app. As far as the current installation regime goes, I'm aiming to keep common-case (single-instance) installation and operation very simple, much like Apache's. 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 their own configuration file which has a syntax patterned after an Apache configuration file; the parsing system uses the ZConfig package (http://www.zope.org/Members/fdrake/zconfig/). I have attached the zope.conf.in file that represents a valid Zope instance configuration file. As an upshot, z2.py no longer exists and the zopectl that runs Zope now on the HEAD knows how to read and interpret the config file. All of the settings you've made configurable within, e.g. your 'default.conf' are configurable via this config file. Additionally, ZConfig lets you perform a textual include of external files into a config file; if you've got common settings in one config file, you can customize the settings for an instance in a small instance config file and %include the common config file into it (even via an HTTP GET if necessary). See the zconfig docs for more information. I'd love to see your zopectl system work with Zope 2.7, and though I likely wouldn't want to package it with Zope, I'd love to see it be able to operate as a front end controller for multiple Zope 2.7 instances. It will not work against the current Zope HEAD because the HEAD no longer has z2.py (everything about Zope startup has changed post-2.6). If you want it to support Zope 2.7, I'd be happy to answer any questions about the new installation/startup process. In particular, I think you'd need to change your zopectl conf file. Instead of keeping all configuration options in the zopectl.conf file, each instance section could keep a smaller set of keys. For example: [Zope] Config-File: /path/to/instance/etc/zope.conf [Instance2] Config-File: /path/to/instance2/etc/zope.conf .. etc... The instance config files could %include a common /etc/zope.conf config file with most of the default settings (instead of using a [DEFAULT] section). You could then throw away most of your parsing code in ZopeCTL.py, and instead of running z2.py in your __start method, run the zopectl associated with the software home, pointing it at the proper config file. FWIW, I'd be very opposed to any sort
Re: [Zope-dev] 2.7 installation
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. 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 support for Python Labs and branding.) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 you're going to have a policy shoot-out: http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.4.html /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application should be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries. Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share. http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.7.html The /usr/share hierarchy is for all read-only architecture independent data files. 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. Perhaps it is a little premature preaching about conformance to the FHS when Zope's package doesn't conform to the Python policy (to which I cannot link because I cannot find a static URL - see /usr/share/doc/python/python-policy.txt.gz). Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy. As demonstrated, Python complies with the FHS. I see no active or archived serious policy violation bugs relating to Python's FHS compliance. What is the status of the Python Policy? a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.7 installation
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 support for Python Labs and branding.) I'm not sure what you mean by that final remark, but I also like to install scripts with their .py extension. Some at PL disagree though. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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/instance/zopectl.py start or zopectl.py start /path/to/zope/instance is a 6/half-dozen affair really. Agreed. But see below. Your system is a perfect example of a value-added frontend for zope. ... I'd love to see your zopectl system work with Zope 2.7, and though I likely wouldn't want to package it with Zope, I'd love to see it be able to operate as a front end controller for multiple Zope 2.7 instances. Agreed; we can have a separate zopectl package that is dedicated to managing instances. [Zope] Config-File: /path/to/instance/etc/zope.conf [Instance2] Config-File: /path/to/instance2/etc/zope.conf Thank you, Chris, you answered your own question! This is a nice simple front-end to a multi-instance zope setup. 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 way to run multiple Zope versions on the same machine sanely because different Zope versions have different libraries. 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? If the concern is because *developers* want to run multiple Zope instances on multiple Zope versions with multiple Python versions, then I would suggest writing an *alternative* mechanism for developers to mangle their PYTHONPATHs and whatever. That said, if you always manage upgrades via your package distribution mechanism, and you only allowed one version of Zope to be package-installed on the machine at once, perhaps putting the files in site-packages wouldn't be such a big deal. This is doubtless the most common scenario (or it should be). I'm afraid you're going to need to change a lot of things to support Zope 2.7. Please let me know if I can help. Should we move this to debian-python? Servicing the many goals of installation and configuration is very difficult, but I'm pretty confident we can make your life a little easier in the long term given that I understand your requirements. It will also make Zope that much more debian-friendly in the long run. As long as we can distinguish those parts of this exercise that will apply to the Zope distribution from those that should be specific to Debian's package, this shouldn't be too hard. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 subdirectory (like site-packages/zope270 or site-packages/zope271). Otherwise there will be no way to run multiple Zope versions on the same machine sanely because different Zope versions have different libraries. 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? It's often the case that you want to upgrade to a new Zope (or Python) version on a machine and it's desirable that you be able to run both the older version and the newer version on the same machine during the cutover. For this reason (and others), during production rollouts Zope Corporation actually never uses the system-installed Python on a machine nor does it use binary-packaged Zope distributions. Instead, we install a whole separate tree (typically inside of /home/zope) using CVS and various source buildouts that looks like this: bin/ (control scripts) opt/ (software like Zope, Python, Apache, Zope products, etc.) var/ | |--zope/ (zope instance and data files) | |--apache/ (apache instance and data files) 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. We never install any Zope-related files to a particular Python's site-package directory (even the Pythons we install ourselves) because we like the flexibility of being able to use any Python version we like without needing to copy Zope library files over between Python site-package directories. We just use the stock Zope software home blob and munge the PYTHONPATH as necessary. This works out pretty well in practice because we never have any dependency on any system installed software besides C libraries, CVS, make, and the shell. This makes it easy to deploy Zope to many (possibly divergent) systems without thinking too hard about system incompatibilities and what's installed in a particular Python's site-packages directory. If the concern is because *developers* want to run multiple Zope instances on multiple Zope versions with multiple Python versions, then I would suggest writing an *alternative* mechanism for developers to mangle their PYTHONPATHs and whatever. It does benefit developers, but I don't think it's solely for the benefit of developers. It seems that most large systems install themselves this way; for instance you can install multiple Apache versions on a single system without regard for them stomping on one another. Same for MySQL, Postgres, etc. It seems to be a fairly common pattern. The fact that we depend on Python doesn't seem to make much of a difference from the perspective of someone installing Zope. If Apache depended on Perl, wouldn't necessarily expect my Apache to stop working because I deleted some files from my Perl library directory. That said, if you always manage upgrades via your package distribution mechanism, and you only allowed one version of Zope to be package-installed on the machine at once, perhaps putting the files in site-packages wouldn't be such a big deal. 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 system. That said, it's really a packaging decision. I'm currently most concerned about making Zope to be easy to install from source. If I can add features to the source install to make it easy for binary packagers to package Zope, I'll do so, but I won't limit the source installer to installing to a single predeclared place. The current Zope source tarball install will continue to allow you to install multiple Zope software homes on your system without regard to the Python you use to invoke them. The binary packaging scheme for a particular distribution is up to the packager. We can probably provide support in the setup.py file for installing libraries to site-packages to help binary distributions do so if they choose. I don't think it's a particularly good idea, but I'm not in charge of those distributions either, so my opinion shouldn't count for much. ;-) I'm afraid you're going to need to change a lot of things to support Zope 2.7. Please let me know if I can help. Should we move this to debian-python? Just tell me where to go and I'll go there. ;-) Servicing the many goals of installation and configuration is very difficult, but I'm
Re: [Zope-dev] 2.7 installation
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 thank Fred Drake too; he implemented ZConfig. And Matt Behrens, he wrote most of the setup.py and took the initial cut at overhauling startup. And Shane, he helped Matt a lot, I think. And Evan Simpson, for his work on the original zctl. And Guido, for zdctl. And Richard Jones, for making mkzeoinstance. And Zope Corporation, for paying the ZCers for much of the time required to do this. And so on. ;-) 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 support for Python Labs and branding.) I think the only Python scripts that don't have a .py extension exist in the software home. They are the 'mkzopeinstance', 'mkzeoinstance', and 'zconfig' scripts. I think these should have the extension. This would also make it possible to run them on Windows without specifying an interpreter (Windows shells don't support hash-bangs). There are no Python scripts in the instance home that don't possess the extension. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 system. OK, consider these scenarios. Source install - simplest:: ./configure.py # PREFIX defaults to /usr/local/zope on UNIX # probably C:\\Progra~1\\Zope on Windows make; sudo make install /usr/local/zope/bin/mkzopeinstance.py /var/zope/inst1 /var/zope/inst1/bin/zopectl.py start Looks just like before! 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/zope/default/etc /etc/zope/default echo -e '[default]\n/var/lib/zope/default' /etc/zopectl.conf zopectl.py start default All the above is invoked by ``apt-get install zope``, and the package can use a /etc/init.d/zope to loop through all instances. Multiple pythons, zopes, instances - most complex:: cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 # ... python2.1 configure.py clean python2.2 configure.py --prefix=/opt/zope271-python22 # ... cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 # ... python2.2 configure.py clean python2.2 configure.py --prefix=/opt/zope272-python22 Then you permute these with: python2.1 /opt/zope271-python21/bin/mkzopeinstance.py \ /var/zope/zope271-python21-instance1 python2.2 /opt/zope271-python22/bin/mkzopeinstance.py \ /var/zope/zope271-python22-instance1 # etc. And you have an installation with all permutations of multiple Pythons, multiple Zopes and multiple instances. Does this alleviate your concerns? ;-) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
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 software (and the *system* should only *ever* have one version of the software) and locally-installed packages go in /usr/local, per FHS. The decision to install multiple versions of a package is always a site-local decision, and therefore correctly belongs in /usr/local. I suppose there may be a religious debate a-brewing about whether Zope should install as a Python package into /usr/lib/pythonX.Y/site-packages, or its own package with its own PYTHONPATH. My argument in this debate goes a little like this: A *library* should be installed as a library. Most of Zope's source code is libraries. Zope should install these libraries (packages) according to the regime dictated by the installation of Python that will be used to run Zope. That is, if you are using a distribution-supplied Python to run Zope, you should install into that Python's --prefix. If you are using a custom Python, use whatever regime matches that Python. But remember these are all *customisations*; the defaults all point to the simplest scenario presented earlier. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
