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 )
[Zope-dev] funky side-effects, possible bug in HTTPRequest.py
The last few days I've been working on patch to Zope 2 that will clean
up the textarea size preference handling in the ZMI. Right now, its a
mess. I kept running into this really irritating behavior such that,
when ever I'd go to pull something out of a request object, it'd end
up being found in the 'other' dictionary instead of where I expected
to be (which happened to be 'form'). After getting really curious as
to why this was happening I've managed to track it down to subtle a
change in the way that the HTTPRequest.get method worked between
revisions 1.75 and 1.74 (1.75 being mj's merge of the value tainting
code). The code responsible (assuming the value isn't tainted):
# Untrusted data *after* trusted data
v = self.form.get(key, _marker)
if v is not _marker:
other[key] = v # *boom*
return v
That magical promotion of the key value to the other dictionary is
what tripped me up. This technique, while originally used only for
known convenience variables like URLx or BASEx and for promoting lazy
data, now applies to all variables after revision 1.75. (This isn't
the only spot it gets used now, the tainting changes made it affect
form values, cookies, tainted form values, etc.) It would increase the
speed at which variables are found--but I'm not sure its really an
intended side effect, and now I'll explain how I was bitten by it.
Its not unusual to see people write methods to be published that are
similar too:
manage_main = DTMLFile(edit, globals())
def manage_changeFoo(self, REQUEST, something=None, or_other=628):
# stuff
return self.manage_main(self, REQUEST)
They're a dime a dozen, yay neat. What sometimes makes them more
interesting is when people modify the REQUEST dictionaries to pull
off various behind the scenes fake-like-we-requested-it-that-way
stuff. This is what several of the methods that handled the Taller,
Wider, Narrower, etc. buttons on text area prefs did, and thats why I
ran into it. One of these methods did:
REQUEST.form.update({'something':'x', 'or_other':'y'})
and then it returned a DTMLFile plied with the snazzy new request that
had been tricked out with these fake values now stuck into the form
dictionary. This explains the TALES I saw that was
request/form/something | request/something | default which when I
first saw made wonder if the author was on acid. It was clear to me
that 'something' would never be in other, it wasn't a special variable
and it wasn't being explicitly stuck into the other dictionary by the
code, so why the redundant TALES I wondered? I removed the first
statement, and it broke the functionality. Hmmm!
Until about 20 minutes ago I didn't understand exactly how object
methods got published, but I tracked down the code in Publish.py and
found the mapply() function and now its all clear to me what was
happening. The request object gets mapply'd to the published method,
this means that any positional arguments or any keyword arguments will
get HTTPRequest.get'd out of the request object when they are applied
to the published method, and thanks to the side-effects from revision
1.75 on, it also means any named variables in a method definition will
be promoted into the HTTPRequest.other dictionary. Now, let me just say
- if thats how its supposed to be, so be it - but spin my nipple nuts
and call me Frank, this does NOT strike me as terribly intuitive
behavior.
Anyway, it was a learning experience for me, but I'm not convinced
this isn't a bug. What do you think?
(the patches I spoke of should be ready sometime tomorrowish assuming
I don't run into any other funkyness, I'll post them to the collector)
--
Jamie Heilman http://audible.transient.net/~jamie/
We must be born with an intuition of mortality. Before we know the words
for it, before we know there are words, out we come bloodied and squalling
with the knowledge that for all the compasses in the world, there's only
one direction, and time is its only measure. -Rosencrantz
___
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] Ordered Folder again
Hi, I'm sorry to revisit an problem that I see has been discussed to death last month, but I'd like to propose a change to what has currently been checked in about Ordered Folders into Zope 2.7. What I often want is an easy way to migrate existing sites to the ordered version. So I would propose that all Folders have OrderSupport, but with the following change: - in a folder, has_order_support would be either a boolean, or not present and thus found by acquisition - the zope root would have has_order_support = 0 - OrderSupport.manage_renameObject would do its special stuff only if self.has_order_support is true - dtml/main.dtml would test ordering with a simple dtml-let hasOrderSupport=has_order_support - dtml/folderAdd.dtml would present the user with a choice to basically decide if has_order_support should be set, unset or acquired. - manage_addFolder would take this additional argument and do nothing or create a property for has_order_support. Thus the default behavior would be the same as today, but if a folder is created with the has_order_support property (or if it's set after creation), the subtree would then be ordered. In a CMS that's always what we want. What do you think ? I think it gives the best of both worlds, as it's then very easy to migrate a site. The only downside is, I think that products like BTreeFolder2 would have to add an has_order_support=0 class variable. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] Re: Ordered Folder again
Hi Florent! Florent Guillaume wrote: I'm sorry to revisit an problem that I see has been discussed to death last month, but I'd like to propose a change to what has currently been checked in about Ordered Folders into Zope 2.7. No problem. Welcome to the discussion :) FYI, this is what Brian wrote off-list in reply to my last posting: I could only ok changing the standard Folder if the changes were 100% backward compatible (and ignorable by people who don't care) in all ways: data compatibility, api compatibility, ui compatibility. If nothing else, I can't see how to maintain ui compatibility, and given that lots of people currently have to override manage_main, it seems like it would be hard to come up with a solution that didn't require other product developers to do something to keep up. But I could certainly be wrong :) Basically, I have no philosophical problem with changing Folder, but it is a core enough thing that we can't do it in a way that causes any b/w incompatibility. And now some comments: - in a folder, has_order_support would be either a boolean, or not present and thus found by acquisition - the zope root would have has_order_support = 0 I'm not sure if acquisition is useful in this case: Move a Folder out of that subtree and you lose OrderSupport. That's confusing. Explicit is better than implicit ;) - OrderSupport.manage_renameObject would do its special stuff only if self.has_order_support is true Is there really a need to provide b/w compatibility for this behaviour? The only use case I know is 'ordering-by-heavy-renaming', and people using that should better migrate to the OrderSupport API. - dtml/main.dtml would test ordering with a simple dtml-let hasOrderSupport=has_order_support - dtml/folderAdd.dtml would present the user with a choice to basically decide if has_order_support should be set, unset or acquired. - manage_addFolder would take this additional argument and do nothing or create a property for has_order_support. Thus the default behavior would be the same as today, but if a folder is created with the has_order_support property (or if it's set after creation), the subtree would then be ordered. In a CMS that's always what we want. Would there be any UI to change that property? How would you set it after creation? The only downside is, I think that products like BTreeFolder2 would have to add an has_order_support=0 class variable. Should be easy to detect BTreeFolders. Cheers, Yuppie ___ 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 )
[Zope-dev] Re: Ordered Folder again
Yuppie wrote: Florent Guillaume wrote: I'm sorry to revisit an problem that I see has been discussed to death last month, but I'd like to propose a change to what has currently been checked in about Ordered Folders into Zope 2.7. No problem. Welcome to the discussion :) FYI, this is what Brian wrote off-list in reply to my last posting: I could only ok changing the standard Folder if the changes were 100% backward compatible (and ignorable by people who don't care) in all ways: data compatibility, api compatibility, ui compatibility. If nothing else, I can't see how to maintain ui compatibility, and given that lots of people currently have to override manage_main, it seems like it would be hard to come up with a solution that didn't require other product developers to do something to keep up. But I could certainly be wrong :) Basically, I have no philosophical problem with changing Folder, but it is a core enough thing that we can't do it in a way that causes any b/w incompatibility. I agree that if we change Folder backward-compat is paramount. But FWIW, note that in Nuxeo CPS we've always been using a monkey patch that added ordering to Folder without any problem. (http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/OrderedFolderSupportPatch/) And now some comments: - in a folder, has_order_support would be either a boolean, or not present and thus found by acquisition - the zope root would have has_order_support = 0 I'm not sure if acquisition is useful in this case: Move a Folder out of that subtree and you lose OrderSupport. That's confusing. You can always add it back. Also, in the use cases I envision it's not very common to do that, there is usually one or two roots of ordered folders that contain content objects and that's it. A CMF portal can easily be ordered everywhere without problem. Explicit is better than implicit ;) I could do without it, it would just mean that in my CMS (Nuxeo CPS) any kind of folder creation (for any subclass) would have to explicitely set that attribute. - OrderSupport.manage_renameObject would do its special stuff only if self.has_order_support is true Is there really a need to provide b/w compatibility for this behaviour? The only use case I know is 'ordering-by-heavy-renaming', and people using that should better migrate to the OrderSupport API. Well it doesn't hurt, and keeps the original speed if folder is not ordered. - dtml/main.dtml would test ordering with a simple dtml-let hasOrderSupport=has_order_support - dtml/folderAdd.dtml would present the user with a choice to basically decide if has_order_support should be set, unset or acquired. - manage_addFolder would take this additional argument and do nothing or create a property for has_order_support. Thus the default behavior would be the same as today, but if a folder is created with the has_order_support property (or if it's set after creation), the subtree would then be ordered. In a CMS that's always what we want. Would there be any UI to change that property? How would you set it after creation? Just the Properties tab. You'd have to know the name of the property to add. Or we could add an Ordering tab. The only downside is, I think that products like BTreeFolder2 would have to add an has_order_support=0 class variable. Should be easy to detect BTreeFolders. Yes, in manage_renameObject we could to that. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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 )
[Zope-dev] Patching object class
I have the need to update some persistent objects in a ZODB to change their class. One use case comparable to the one I have would be to change all objects of type Folder to OrderedFolder. To do that, I envisionned finding all thoses objects and doing ob.__class__ = OrderedFolder ob._p_changed = 1 Would this work ? If not, what other hack could I do ? The idea being that I don't want to recreate all the objects. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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 )
[Zope-dev] Re: Patching object class
Florent Guillaume wrote: I have the need to update some persistent objects in a ZODB to change their class. One use case comparable to the one I have would be to change all objects of type Folder to OrderedFolder. To do that, I envisionned finding all thoses objects and doing ob.__class__ = OrderedFolder ob._p_changed = 1 Would this work ? If not, what other hack could I do ? The idea being that I don't want to recreate all the objects. Maybe you should install OrderedObjectManager for bringing order to all your folders. http://www.zope.org/Members/mjablonski/OrderedObjectManager I'll release an api-updated version when 2.7 is released. Cheers, Maik ___ 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: [Zope-dev] funky side-effects, possible bug in HTTPRequest.py
On Fri, Jun 20, 2003 at 03:07:18AM -0700, Jamie Heilman wrote: Anyway, it was a learning experience for me, but I'm not convinced this isn't a bug. What do you think? From the POV of a poor web monkey, my opinion is that this is purely awful. It's the kind of thing that can easily waste hours of debug time. I was just saying to Andy McKay yesterday that sometimes I think zope 2 is designed around the principle of greatest consternation rather than the principle of least suprise. Case in point. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ANTHROPOLOGIST MAN! (random hero from isometric.spaceninja.com) ___ 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] Patching object class
On Fri, Jun 20, 2003 at 04:56:26PM +0200, Florent Guillaume wrote: I have the need to update some persistent objects in a ZODB to change their class. One use case comparable to the one I have would be to change all objects of type Folder to OrderedFolder. To do that, I envisionned finding all thoses objects and doing ob.__class__ = OrderedFolder ob._p_changed = 1 Would this work ? See the thread Renaming a product just a few days ago. The conclusion was that this would not work. If not, what other hack could I do ? The idea being that I don't want to recreate all the objects. You might not have a choice. A conversion script might take a while to run and your ZODB might get a bit more bloated, but otherwise, it'll work fine. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ULTRA BULLET FROGMAN! (random hero from isometric.spaceninja.com) ___ 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 )
[Zope-dev] leave application in zpt + formulator
hi
i had downloaded leave.zexp from the following url
http://www.openflow.it/EN/Download/index_html
I have installded open flow 1.1.0
i have plone,zope on ,my linux box.
Now i tried to rewrite the application using zpt +
formulator(originally written in dtml).
I have written the following zpt files
1)leave_startform_zpt
2)leave_start_zpt
a macro leaveform_macro for leave_startform_zpt
file.
Now my program goes like this
leave_startform_zpt -- macros -- leave_start_zpt --
gotoOF (this is a python file),
Plz see the files in the attachemnt. These are the
files i have added. the other files remain same. no
change
I get the following error like
Error Type
NameError
Error Value
global name 'workflow' is not defined
what is the problem
plz help me
thanks
prasad
Send free SMS using the Yahoo! Messenger. Go to http://in.mobile.yahoo.com/new/pc/
1) leave_startform_zpt
---
html
headtb
title tal:content=template/titleThe title/title
head
body
p metal:use-macro=here/common_pages/macros/leaveform_macro /
/body
/html
---
2) leaveform_macro
---
div metal:define-macro=leaveform_macro
form name=leave_startform_formulator method=post action=leave_start_zpt
table tal:define=form here/leave_startform_formulator align=center
tr tal:define=startdate request/startdate|nothing
th align=left
font size=5font face=verdanab
Start Date:
/b/font/font
/th
tdinput type=text name=startdate
tal:replace=structure python:form.startdate.render(startdate) /
/td
/tr
tr tal:define=enddate request/enddate|nothing
th align=left
font size=5font face=verdanab
End Date:
/b/font/font
/th
tdinput type=text name=enddate
tal:replace=structure python:form.enddate.render(enddate)
/td
/tr
tr tal:define=reason request/reason|nothing
th align=left
font size=4font face=verdanab
Reason:
/b/font/font
/th
tdtextarea type=text name=reason
tal:replace=structure python:form.reason.render(reason)/textarea
/td
/tr
tr tal:define=leavetype request/leavetype|nothing
th align=left
font size=4font face=verdanab
LEA:
/b/font/font
/th
tdtextarea type=text name=leavetype
tal:replace=structure
python:form.leavetype.render(leavetype)/textarea
/td
/tr
tr cols=*,350,*
td /td
td align=centerinput type=submit value= Submit /td
td /td
/tr
/tablebr
/form
/div
---
3) leave_start_zpt
---
html
head
!-- Put your CSS, meta tags and scripts here. --
/head
body bgcolor=#ff
p tal:replace=structure python:here.gotoOF() /
!--p tal:replace=structure
python:here.gotoOF(startdate,enddate,reason,leavetype,requested,formalia,approved,decision)
/--
!--span tal:define=result python:here.mailScript()/span--
/body
/html
---
4) gotoOF
---
no parametres for this.
instance=workflow.addInstance('leaverequest',AUTHENTICATED_USER.getUserName(),'no
comment','Request for leave by ' + AUTHENTICATED_USER.getUserName(), activation=0)
instobj=_.getattr(workflow,instance)
form = context.leave_startform_formulator
instobj=getattr(workflow,instance)
instobj.manage_addProperty('startdate', startdate, 'string')
instobj.manage_addProperty('enddate', enddate, 'string')
instobj.manage_addProperty('reason', reason, 'text')
instobj.manage_addProperty('leavetype', leavetype, 'string')
instobj.manage_addProperty('requested', '', 'string')
instobj.manage_addProperty('formalia', '', 'string')
instobj.manage_addProperty('approved', '', 'string')
instobj.manage_addProperty('decision', '', 'text')
workflow.startInstance(instance)
print Done
return printed
---
Re: [Zope-dev] Patching object class
On Fri, Jun 20, 2003 at 04:56:26PM +0200, Florent Guillaume wrote: | I have the need to update some persistent objects in a ZODB to change | their class. | | One use case comparable to the one I have would be to change all objects | of type Folder to OrderedFolder. | To do that, I envisionned finding all thoses objects and doing | | ob.__class__ = OrderedFolder | ob._p_changed = 1 | | Would this work ? | | If not, what other hack could I do ? The idea being that I don't want to | recreate all the objects. You need something like this: http://cvs.zope.org/Products/ZopeOrg-NV/Extensions/change_modules.py?rev=1.2cvsroot=Zope.orgcontent-type=text/vnd.viewcvs-markup BIG BOLD WARNING: = Backup your data before using it. []'s -- Sidnei da Silva (dreamcatcher) [EMAIL PROTECTED] X3ng Web Technology http://www.x3ng.com.br GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.20-powerpc ppc You're already carrying the sphere! ___ 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] Patching object class
Sidnei da Silva wrote: You need something like this: http://cvs.zope.org/Products/ZopeOrg-NV/Extensions/change_modules.py?rev=1.2cvsroot=Zope.orgcontent-type=text/vnd.viewcvs-markup Thanks, I see there is indeed some deep voodoo involved... Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] funky side-effects, possible bug in HTTPRequest.py
Jamie Heilman wrote: [major snippage] Hmmm, that means that this changes break exactly these applications, which, in order to be on the secure side, explicitly use REQUEST.form['bla'] more than once in a request, right. Ironic. cheers, oliver ___ 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] funky side-effects, possible bug in HTTPRequest.py
Jamie Heilman wrote at 2003-6-20 03:07 -0700: ... That magical promotion of the key value to the other dictionary is what tripped me up. This technique, while originally used only for known convenience variables like URLx or BASEx and for promoting lazy data, now applies to all variables after revision 1.75. Zope promotes the variables from cookies and form to other at least since Zope 2.1.6 (the first version I worked with). I think this is for efficiency reasons. You have a single dictionary lookup instead of three (other, form, cookie). Dieter ___ 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] Patching object class
Florent Guillaume wrote at 2003-6-20 16:56 +0200: I have the need to update some persistent objects in a ZODB to change their class. One use case comparable to the one I have would be to change all objects of type Folder to OrderedFolder. To do that, I envisionned finding all thoses objects and doing ob.__class__ = OrderedFolder ob._p_changed = 1 Would this work ? It will not work (at least it did not when I last tried it). The __class__ assignment was simply ignored (no error, it was just that the class did not change). If not, what other hack could I do ? The idea being that I don't want to recreate all the objects. I follow Maik: Give OFS.Folder.Folder (or even ObjectManager) Orderable support. Dieter ___ 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] funky side-effects, possible bug in HTTPRequest.py
Oliver Bleutgen wrote: Jamie Heilman wrote: [major snippage] Hmmm, that means that this changes break exactly these applications, which, in order to be on the secure side, explicitly use REQUEST.form['bla'] more than once in a request, right. Naw, it doesn't break them, promotion doesn't mean the vars are actually moved from the form dictionary to the other dictionary, only copied. What it does is humble the poor shmuck who thought he knew the dangers of REQUEST.get well enough to use it without shooting himself in the foot. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy ___ 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] funky side-effects, possible bug in HTTPRequest.py
Dieter Maurer wrote: Zope promotes the variables from cookies and form to other at least since Zope 2.1.6 (the first version I worked with). I think this is for efficiency reasons. You have a single dictionary lookup instead of three (other, form, cookie). Yeah most promotion is for efficiency, but since 2.1.6 eh? Interesting, that means its happening elsewhere too. Hmm. Yeah, I see, it happens in __init__ for cookies, mmm and in processInputs for form variables I guess. The difference I can see is two fold, first, before 1.75 I believe promotion of form and cookies was only done during request object creation, interestingly, its not done there anymore from the looks of it; cookies and form vars are kept in their seperate tainted non-tainted buckets until they are fetched. Second the promotion of cookies wouldn't clobber pre-existing keys in other, interestingly, in 2.1.6 times, form vars would clober normal other vars (URLx, BASEx, etc.). I must admit, this isn't the biggest deal to me, I just blew quite a bit of time tracking it down because I couldn't understand why the promotion was happening and I don't like surprises, and nothing about def foo(self, bar, baz): immediately jumped out and said to me, promote bar and baz form vars and cookies to the other dictionary. Now that I have an appreciation for exactly how methods are published, I see things in a different light of course. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer ___ 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] Zope 2, Zope 3, now, (was funky side-effects, possible bug in HTTPRequest.py)
On June 20, Jamie Heilman wrote: and I don't like surprises Zope 2 is probably not the most suitable choice, then. ;-) More seriously, though, my colleagues and I will often find a few of these sorts of *surprising* things in Zope 2 every week. It's really quite demoralising building for Zope 2 when it feels like such a dead effort, with many (seemingly rather deep) problems in Zope 2 that nobody has either the time or motivation to fix, because all the interesting work is happening on Zope 3. Are there, or will there be, any guidelines for developing for Zope 2 with the view to migrating to Zope 3? And given the logevity of Zope 2 suggested by the roadmap, will there be any effort to clean up the Zope 2 code in the medium/long term? FWIW I use Zope for its webblication features over its CMF features, which is why Zope 3 is far more interesting than most of the work happening around Zope 2. I understand that things are moving quite well with Zope 3 but the current state of affairs does put places like ours, with a commitment to producing a large, complicated Zope 2 extranet/portal in a number of months, in a confusing headspace. 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] Zope 2, Zope 3, now, (was funky side-effects,possible bug in HTTPRequest.py)
I'll quote the (seemingly late) Andrew Kenneth Milton wrt Zope 2: http://www.zope.org/Members/mcdonc/Silly/newzopelogo ;-) On Fri, 2003-06-20 at 20:35, Adrian van den Dries wrote: On June 20, Jamie Heilman wrote: and I don't like surprises Zope 2 is probably not the most suitable choice, then. ;-) More seriously, though, my colleagues and I will often find a few of these sorts of *surprising* things in Zope 2 every week. It's really quite demoralising building for Zope 2 when it feels like such a dead effort, with many (seemingly rather deep) problems in Zope 2 that nobody has either the time or motivation to fix, because all the interesting work is happening on Zope 3. Are there, or will there be, any guidelines for developing for Zope 2 with the view to migrating to Zope 3? And given the logevity of Zope 2 suggested by the roadmap, will there be any effort to clean up the Zope 2 code in the medium/long term? FWIW I use Zope for its webblication features over its CMF features, which is why Zope 3 is far more interesting than most of the work happening around Zope 2. I understand that things are moving quite well with Zope 3 but the current state of affairs does put places like ours, with a commitment to producing a large, complicated Zope 2 extranet/portal in a number of months, in a confusing headspace. a. ___ 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 )
