Re: [Zope-dev] [ZConfig] import inhomogenous
On Tuesday 17 February 2004 01:10 pm, Dieter Maurer wrote: It would be better if the type of the imported object (schema or component) were orthogonal to the location from where the object is found (in a package or via an URL). I agree, that does seem nicer. Another approach would be to deprecate the import src=url/ form, so we only need to deal with components. The original src=url flavor was created before schema components had been thought through, and I'd be happy to see that go. A use case is the import of the section types defined in Zope.Startup.zopeschema.xml for other ZEO applications that require access to the same ZODB database(s). It is far more convenient to access this schema via package+file than an URL. Is there some reason not to simply move the section types to a schema component? That seems more in the spirit of making the schema modular. The attached patch adds an additional type attribute to the import element. It can take values schema or component and determines the type of object to be imported. Its default value () is handled to provide backward compatibility. I've not read the patch yet, so I'll ask: what's the point of the type attribute? Should it be an error if the type doesn't match the top-level element of the resource? If only advisory, is it actually useful? Thanks for thinking critically about ZConfig. Yes, I'm aware there are some proposals for changes I've not yet addressed. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] server for new protocol?
On Thursday 26 February 2004 06:50 am, Nikolay Kim wrote: is there any way create server for new protocol without changing ZServer module? There's clearly a need for some more documentation here, but I'm not sure what to write yet, or where it should go. Contrary to many of the other responses, yes, this shouldn't be difficult at all. You'll need a couple of pieces of Python code: 1. Your server implementation. It sounds like you have this already. 2. A factory object that can accept configuration data and create an instance of your server object. You then need to create a ZConfig component that provides a section type to support your server. The ZConfig documentation discusses this somewhat. The new section type will need to declare that it implements the ZServer.server abstract type; it should probably look something like this: component import package=ZServer/ sectiontype name=myserver implements=ZServer.server datatype=mypackage.server.ServerFactory !-- configuration data should be described here -- /sectiontype /component You'll need to arrange for the package containing this component is available on the Python sys.path before zope.conf is loaded; this is mostly easily done by manipulating the PYTHONPATH environment variable. Your zope.conf file can now include the following to load and use your new server: %import mypackage myserver # configuration settings go here /myserver Feel free to ask questions about this; I'm usually more available to respond than I have been a couple of days. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] server for new protocol?
On Sunday 29 February 2004 11:21 pm, Nikolay Kim wrote: P.S. i'm developing smtp server for zope and already have working code. Ooh! This is really cool. Will this be open source? I'll be a lot of people will be interested in this. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Product directory?
On Tuesday 09 March 2004 01:58 pm, Ian Beatty wrote: This has to be an easy one. Good, I'll take it. ;-) From within my Python-based product's code, how do I get access to the product's directory on the filesystem? os.getcwd() seems to provide the working directory of the shell used to launch Zope, at least when running in debug mode. This isn't actually Zope specific; you can easily get the directory a module lives in using this: import os here = os.path.dirname(os.path.abspath(__file__)) The variable here will hold a string with an absolute path to the directory containing the source file for your module (named by __file__). The call to os.path.abspath() isn't strictly necessary, but protects against future calls to os.chdir() (though not past calls!) in case the module was loaded from directory named by a relative directory on sys.path. You can do this just once at module scope; there's no need to recompute this each time you need it. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Product directory?
On Tuesday 09 March 2004 02:30 pm, Chris McDonough wrote: There is also a convenience function for this in Zope: from Globals import package_home here = package_home(globals()) Maybe I'm just weird, but I generally prefer the general approach when there's not a clear improvement in readability or brevity. Globals.package_home() is definately a more complicated approach to digging out the same information; it might be better for older versions of Python. It's not available in Zope 3. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Re: test.py
On Thursday 11 March 2004 10:40 am, Tres Seaver wrote: #!/usr/bin/python2.3 distutils will munge it anyway, if it installs the scripts. That won't work for a lot of developers, I'll bet, who have python2.3 installed in /usr/local/bin. The env hack is more reasonable for developers; since distutils is going to munge the sh-bang line anyway, it's not an issue for real installations. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: test.py
On Friday 12 March 2004 05:40 am, yuppie wrote: I don't care much *how* this is resolved, but I'd like to have this consistent and up to date. If I always have to check if the python version is set correctly that line isn't helpful at all. Well, Tres appearantly hasn't had time to respond. I think the line should become: #!/usr/bin/env python2.3 This will then be modified on installation by distutils to point to the Python interpreter which was involved in the installation. I think this is the right thing for both developers working from CVS and site developers and administrators working with installed versions. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] ZPT for CSS, anyone?
On Tuesday 30 March 2004 01:40 pm, Dieter Maurer wrote: Furthermore, stylesheets often contain customization variables, e.g. for a color scheme. I think, this is useful. This is one of the most painful warts in CSS that would have been really easy to do right, I think. Being able to name colors for parts of pages and then reuse those names would make a lot of this sort of problem go away for style sheets where the colors are the only difference. CSS 3 might include this, but I've not tracked it closely. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope-Coders] Re: CVS: Zope3/src/zope/tal - talparser.py:1.6
On Thursday 08 April 2004 10:00 am, Philipp von Weitershausen wrote: I would like to backport this patch (including tests) to Zope 2, since I need to i18n XML generated by ZPTs. None here. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] ZConfig 2.1 released
I've posted a distribution for ZConfig 2.1 on the ZConfig page: http://zope.org/Members/fdrake/zconfig/ This fixes a few bugs and improves the ability to set default values in schemas. It also adds some helpful schema building blocks, including a general mapping type and support for Python's logging package. This version of ZConfig requires Python 2.3. From the news file: - Removed compatibility with Python 2.1 and 2.2. - The default objects use for section values now provide a method getSectionAttributes(); this returns a list of all the attributes of the section object which store configuration-defined data (including information derived from the schema). - Default information can now be included in a schema for key name=+ and multikey name=+ by using default key= - More documentation has been added to discuss schema extension. - Support for a Unicode-free Python has been fixed. - Derived section types now inherit the datatype of the base type if no datatype is identified explicitly. - Derived section types can now override the keytype instead of always inheriting from their base type. - import package='...'/ makes use of the current prefix if the package name begins witha dot. - Added two standard datatypes: dotted-name and dotted-suffix. - Added two standard schema components: ZConfig.components.basic and ZConfig.components.logger. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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 Developers
On Tuesday 13 April 2004 01:44 pm, Paul Edward Brinich wrote: I was wondering if someone on this list could point me in the direction of an appropriate place to post Zope job openings. I am looking for an audience well-versed in Zope. Thanks for any guidance! There's the Python Job Board: http://www.python.org/Jobs.html -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] zLOG is dead
zLOG is dead The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library. The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or façade) over the logging package. It is expected to wither away to nothing at some point. Why should you care? This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself. If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim. How can you help? - If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Re: Zope and zope
Jim Fulton noted: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote: -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote: You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] zLOG is dead
On Wednesday 14 April 2004 01:49 am, Andreas Jung wrote: What is the recommend way to migrate existing code? I assume using: import logging logger = logging.getLogger(loggername). That works, and certainly matches what I've been doing, and what we see in the Zope 3 codebase as well. When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST packagebetter using 'Zope' or 'reST'? I don't think there is a general convention at this time; where I've switched things over (only a few places), I've used what was being passed to zLOG.LOG as the subsystem parameter. Where there's no precedent... I don't know. A guiding convention would be nice; I could see using the package name if there's nothing else that sticks out as obvious. That doesn't match a lot of the existing usage, though. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Re: [Zope3-dev] Zope and zope
On Wednesday 14 April 2004 09:54 am, Kapil Thangavelu wrote: its probably a problem imo for mac users who are on a case insensitive fs. Is this still an issue for Mac OS X, or is your concern for classic Mac OS? I don't know if we support that (simply because I've never heard anyone mention it). none of the alternative seem all that appealing though.. the comment No, they don't. The current Zope 3 naming for modules and packages mostly follows the current BDFL recommendations, which is nice, and is friendly to to those of use alergic to upper case letters. It also works well for case-senseless filesystems. about most z3 imports being prefixed with zope, suggests that any backwards porting with a goal of forward compatibility will require changing the existing z2 Zope package to something else, although sticking version numbers on package names doesn't hold much appeal for me. perhaps renaming z2 Zope-Core The Zope 2 Zope package is actually quite small. Perhaps renaming it is the best approach. In spite of Tres's objection, I don't see how there could be all that much code that references it. Perhaps it's referenced by some persistent objects? There's an uncertain comment in Zope.ClassFactory, and Zope.App.ClassFactory might be referenced, but otherwise the Zope package contains startup code. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] zLOG is dead
On Wednesday 14 April 2004 11:44 am, Lennart Regebro wrote: Yeah, but is it reasonable to think that people who write new products will do this? A rule that most people will break is a bad rule... That people working on Zope itself can be well versed enough to use Zope. for things in teh Zope repository seems reasonable. But will people working on Plone really use Zope.CMFQuickInstaller? Rather they will probably say just CMFQuickInstaller, CMF.QuickInstaller och Plone.QuickInstaller or something. I would only expect any sort of leading Zope. to apply to the software that ships as part of Zope 2. Other products and tools, like the CMF and Plone, should use a different prefix (CMF. and Plone. come to mind as reasonable candidates). -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Zope and zope
On Wednesday 14 April 2004 10:52 am, Jim Fulton wrote: packages become very unsttractive. It turns out that pkgutil will be confused by the Zope package on Windows or Mac OS, adding it's directory to the zope package's path. This is a bug in pkgutil that can be fixed, but it is an example of the sorts of problems we can expect. I've filed a bug report on pkgutil: http://www.python.org/sf/935117 -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] zLOG is dead
On Wednesday 14 April 2004 10:45 am, Andreas Jung wrote: For consitency: Zope.Products. For lazy writers: Zope. X I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly. I disagree. Not everyone that looks at the logs will be a site developer or Zope product or core developer. Keeping things explicit is reasonable. Keep the product name as it is...means Products/ should use Zope. as logger name. No need to introduce a new mapping. Keep it simple. Keeping it simple is good, but I'd still like to see every logging subsystem in code that ships with the Zope 2 core start with Zope. This is a potential backwards compatibility issue, though, since log-trawling tools are already using the names currently generated, as inconsistent as they are. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev], [Zope-dev] More arguments for z (was Re: Zope and zope)
On Thursday 15 April 2004 10:23 am, Jim Fulton wrote: (BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.) I won't disagree with this. ;-( The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z. As long as z gets installed *at all* (before/after is not an issue), we can do this now. This is supported, if only by accident, by the current implementation of distutils. I think that that's a different discussion. The safest thing to do for now is to continue using a container package. I like this as well. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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 )
[Zope3-dev], [Zope-dev] Import checking code
On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py ... which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. I keep meaning to get back to you about this; sorry it's taken me so long. I wrote the tokenize-based code before I saw your importchecker.py code; I'd decided to go with the tokenize module instead of the compiler package since the later was poorly documented (IMHO). I've no really strong feeling about either approach being better. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. I'm not sure simply re-implementing one of the finddeps.py internal interfaces is the right thing to do; that's some incredibly cludgey code in Zope 3. There's a lot of confusion about what values are paths and which are module names, and that makes me very uncomfortable. If you'd like to replace the code that locates imports, feel free to do so. It may be that conciseness wins; the tokenize-based approach certainly ended up being more code than I'd expected initially. On Thursday 15 April 2004 01:21 pm, Stephan Richter wrote: Fred has fixed that a while ago already (if I read the checkins correctly). :-) No, Martijn's talking about something else... kinda. I imagine he had even stronger feelings about your initial implementation. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Proposal: Rename zope package
On Friday 16 April 2004 01:31 pm, Michael Bernstein wrote: From a consistency in nomenclature POV, I find 'z' jars a bit with ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find nested within 'z' (as 'z.Config' for example). This is admittedly only an issue for the newest newbies still trying to guess at where stuff is located. I don't know what zLog is; presumably you mean zLOG? zLOG is dead in Zope 2.8, and will remain only for API compatibility. I don't think there's any real consistency now for what's in the Zope 2 head, so I don't think that's a big deal. However, rather than suggest a wholesale moving and renaming of these packages within 'z', I'd like to suggest an alternative short name for the 'zope' package, 'OPE', which avoids this issue: import OPE.interface from OPE.app import zapi from OPE.app.event import publish from OPE.app.event.objectevent import ObjectModifiedEvent Hehe. ;-) (I do hope you're joking!) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Proposal: Rename zope package
On Friday 16 April 2004 03:06 pm, Michael Bernstein wrote: Shouldn't we strive for consistency in nomenclature going forward? Definately. My point was that we don't have anything to base it on, not that we shouldn't be. Zope 3 kindly specifies some guidelines for naming, including module and package names. I'm not convinced z follows those guidelines (actually, I'm also not convinced it doesn't, given that the official expansion for ZOPE is the Z Object Publishing Environment). About even considering a 'wholesale moving and renaming' yes, obviously, but as far as suggesting 'OPE' as an alternative to 'z' (insofar as it is still necessary to avoid a name-clash with 'Zope'), no. 'OPE' (as an acronym for Object Publishing Environment) seems like it fits better conceptually than 'z'. From where I stand, calling it OPE (or ope, or Ope) are all the same mistake as Interface, transaction, persistent, Persistence, etc: taking a very general term and using that for a specific implementation. We're not dealing with some abstract or archtypical object publishing environment, we're dealing with a specific one. Whether or not z is a good name for it is another question altogether. ;-) Did I miss something? Did I just manage to embarrass myself? Is this a dream where I find I am wearing nothing but underwear in public and then wake up? That's better than dreaming you're wearing a suit in a dream, and waking up wearing nothing but your underwear in public. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Proposal: Rename zope package
On Friday 16 April 2004 03:24 pm, Shane Hathaway wrote: - Spelling it zOPE to take advantage of a frequent mishap involving the cAPS lOCK key That must be what happened for zLOG, and I declared that dead. I don't think anyone's ready for that for Zope 3 just yet. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: zLOG changes
On Tuesday 20 April 2004 01:22 pm, Andreas Jung wrote: - the entries in the event.log are currently written without the log level. Is this dedicated behaviour? I think the log level should be part of the event.log It should. This was lost when I changed the zLOG -- logging mapping, and was unintentional. I've changed the default logging formats for each handler type to do what seems to be the right thing. The specific formats can be controlled via the format setting in the relevant log handler sections in zope.conf. - when adding LOG = getLogger(...) LOG.info(...) to some modules then the output is only written to the event.log but no longer to stdout (if running in debug mode). Is this change intentional? I'm not sure what the right approach to fixing this is. There are a couple of choices: - In debug mode, add a new handler that dumps to standard output. This is fairly easy to code, but is inflexible. - In debug mode, use an alternate or auxillary logging configuration to replace or augment the eventlog configuration section. This is more work up front, but keeps everything flexible. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Re: zLOG is dead
On Tuesday 20 April 2004 01:15 pm, Christian Heimes wrote: Fred Drake wrote: * Do I need to take care that the messages are logged into the event log and on the console or can I safly use the logging package like:: ... zLOG has logged the messages to the console when zope was started with runzope and the entries were logged to the event.log, too. I've responded to the note from Andreas; we need to decide just how this should be handled, but it should not require changes to code that uses logging. * Does Zope 2.7.0 has the new logging facility? Zope 2.7.x uses the logging package as a back-end to zLOG, but it uses it in a different way. For it to make sense to change this for 2.7.1 would mean backporting most or all of the relevant changes from the trunk. I've no plans to do so myself at this time. So for code that needs to be compatible with Zope 2.7.x, it's wise to stick with zLOG. * If no: Will Zope 2.7.1 have the new logging facility or do I need to wait for Zope 2.8? I think waiting until you can drop support for Zope 2.7.x is the right thing to do. I imaging the zLOG API shim will remain in Zope 2.x for a long time. I'm chatting with Andreas Jung right now. He is telling me that the logs don't get printed to the console and that the log level is missing in the event.log This was unintentional; you should have better results after an update from CVS. Thanks for bringing this up. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Re: zLOG changes
I wrote: - In debug mode, add a new handler that dumps to standard output. This is fairly easy to code, but is inflexible. Andreas responded: But flexible enough for most usecase. The point is that you want to see the tracebacks on the console during the development phase. Watching the event.log with tail -f is somewhat annoying. Understood! I've committed changes that that I think should do the trick for you. - In debug mode, a log handler is added to the root logger that writes events to standard error. This is no longer conflated with the startup logging. - When running Zope using zopectl fg (the best way to run things for debugging), zopectl will force debug mode to be enabled. - In debug mode, use an alternate or auxillary logging configuration to replace or augment the eventlog configuration section. This is more work up front, but keeps everything flexible. Maybe too much overkill...not sure if one needs an academic solution here... I don't know that I'd describe this as academic (most academics I've worked with considered the ability to change the code configuration enough), but if you're happy not to need it, I'm happy not to implement it. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Re: zLOG changes
On Wednesday 21 April 2004 04:48 am, Chris Withers wrote: I'm guessing there is some kind of log-to-console logger already? If so, why not just add that in zope.conf and comment it out when you move to production? That would work for me, but not everyone at ZC agreed, so I've made some changes that should be good for most people; see my message to Andreas and (and Zope-Dev) for a description of how things work on the trunk now. BTW, is there a logger in Python 2.3/Zope 2.7 that sends log entries via email? If not, I'll port MailingLogger to Zope 2.7 and see if I can make it play nice :-) Yes, there is. You should be able to use it by adding a section like this inside your eventlog section in zope.conf: email-notifier fromChris Withers [EMAIL PROTECTED] to [EMAIL PROTECTED] to [EMAIL PROTECTED] subject Something blew up! smtp-server [EMAIL PROTECTED] level error format Timestamp: %(asctime)s\nComponent: %(name)s\nLevel: %(levelname)s (%(levelno)s)\n\n%(message)s /email-notifier My mailer might have wrapped that long line; sorry. ;-( Let me know if there are any problems with this. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] New mailing list for ZConfig users
At a suggestion from the community, I've created a new mailing list for ZConfig users. This is for general discussion and questions. The list is run using Mailman at Zope.org; you can sign up at http://mail.zope.org/mailman/listinfo/zconfig/ -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Need help with http://dev.zope.org/Subversion
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote: cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 That should be: svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 cvs co http://svn.zope.org/repos/Zope3/trunk Zope3 and this would be: svn co http://svn.zope.org/repos/Zope3/trunk Zope3 -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Need help with http://dev.zope.org/Subversion
On Sunday 25 April 2004 01:00 pm, Jim Fulton wrote: Oops. Thanks. I gues some habits will be hard to kick. :) Yeah. Of course, CVS isn't just an old habit; it'll still be current practice, not just for Zope 2.6.x and 2.7.x, but for lots of projects. The general pain of two widely-used revision control systems will be with us for a long time. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: Mailing Log Entries in 2.7
On Saturday 24 April 2004 06:26 pm, Chris Withers wrote: And there was me looking forward to writing a product that added its own ZConfig section :'( You still can if you like. ;-) Okay, how can I get the log level and exception type into the subject? That's not currently possible, though it wouldn't be hard to add. Perhaps some future ZConfig revision would add this. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] What do we want to bring from CVS to Subversion
On Monday 26 April 2004 03:23 pm, Jim Fulton wrote: 2. Convert the mainline history, but leave off the branches. This sounds good to me. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: Should we require windows users to use tools that honor Unixlineendings? (Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs tosubversiontransitiontomorrow)
On Wednesday 28 April 2004 04:01 pm, Lennart Regebro wrote: Yes, but I'm pretty sure there are default settings for which files that should be treated as binary on the server side in CVS. At least I rember setting it up. :´) Yes, this is specified in the CVSROOT/cvswrappers file. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] [Weakness] analysis of Zope startup problems
On Friday 30 April 2004 10:50 am, Chris McDonough wrote: Is this improved at all by Fred's latest zZLOG-removal checkins? If not, I will open a collector issue. None of my changes have been applied to Zope 2.7; they only exist on the Zope 2 HEAD. The removal of zLOG is only for the Zope 3 and ZODB distributions; there's no intention to remove it from Zope 2. On Fri, 2004-04-02 at 03:34, Dieter Maurer wrote: Zope 2.7 delays access to log files until Zope is properly set up. This means: log files cannot be used to analyse startup problems. It may be that some of the changes to Zope.Startup could be backported to improve the situation, but others are probably needed as well. I'll be glad to help out with this, but can't do this right now. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Re: [Zope-Coders] End-of-line translation problem
On Friday 30 April 2004 12:25 pm, Lennart Regebro wrote: Only that the Subversion people are wrong. Ad-hoc is not good enough. It must be able to be configurable on the server. Another possible approach would be to write a script to use for adds instead of the default client; it could set all the right attributes as part of the add operation (do the svn add and then set the properties). The script could have our initiali policy hardcoded, and could import the policy configuration from the server (caching it and all that of course). This would mean adds have to be done with the custom client though, which could be a real problem for people who'd rather use TortoiseSVN. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Proposal: cvs to subversion transition May 11 (?)
On Wednesday 05 May 2004 01:59 am, Jim Fulton wrote: I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG). +1 -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: Mailing Log Entries in 2.7
Regarding putting more information in email's generated using email-notifier sections, I wrote: That's not currently possible, though it wouldn't be hard to add. Perhaps some future ZConfig revision would add this. On Wednesday 05 May 2004 05:41 am, Chris Withers responded: Surely ZConfig alredy allows this, it's just Zope's use of ZConfig that needs to support it? The configuration of the logging is handled using a ZConfig component that's actually bundled with ZConfig itself on the Zope 2 head; it's in the package ZConfig.components.logger. This allows any project using ZConfig to use the same basic logging support; we actually have several projects using ZConfig outside the application server. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] cvs.zope.org wedged, we're looking into it
On Friday 07 May 2004 01:50 pm, Ken Manheimer wrote: cvs.zope.org is wedged - you can connect to it (ping, web, ssh) but not get any further. We've got a call in for attention, hopefully it'll be back available soon... Yay! It's working again! Ken, you're my hero. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Re: SVN: Zope3/trunk/functional_tests/ Remove unused directory.
On Wednesday 26 May 2004 08:42 am, Philipp von Weitershausen wrote: That works for me too, but please *above* the diff. Yes; I should have been more clear and said *immediately* following the commit message. No, the CVS should stay in there to tell them apart, for the very same reason you stated (patches in both CVS and svn). Without the 'SVN:', it will still be unique. I would even argue that it would make it visually easier. Right now, my email client lists a lot of: Ok; like I said, I don't feel very strongly about this. Sure. I'm not saying that we should convert everything *right* now, but moving relatively independent stuff makes sense, IMO. I'm not suggesting to move CMF or something else with a gazillion branches... Cool. zpkg is a good candidate, since it's not shared with other projects, it's a stand-alone tool. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] INSTANCE_HOME and SOFTWARE_HOME still necessary in 2.7 start script?
On Thursday 01 July 2004 07:42 pm, Chris Withers wrote: Is it still necessary to specify INSTANCE_HOME and SOFTWARE_HOME in the start script for Zope? I'm pretty sure I removed that requirement long ago, back when I added the App.config module. Or would the following work? python /my/path/to/Zope/startup/run.py -C /my/instance/path/zope.conf Try instead: /my/instance/path/bin/runzope -Fred -- Fred L. Drake, Jr. fred at zope.com Zope Corporation ___ 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] TAL Hotfix 2004-07-13 for Zope 2.7.0, 2.7.1
This hotfix product fixes a security bug in Page Templates. This fix ensures that values substituted in named slots in translated elements are properly encoded. If encoding is not desired and the source of the replacement text is trusted, the structure modifier can be used with the tal:content or tal:replace attribute to explicitly disable encoding. Affected Versions This fix applies to Zope 2.7.0 and 2.7.1. Zope versions 2.7.2 and newer already contain this fix, and do not require this hotfix. Getting the Hotfix You can download the hotfix at: http://zope.org/Products/Zope/Hotfix_2004-07-13/Zope%202.7.0%20-%202.7.1/ The product contains a README.txt file with installation instructions. -Fred -- Fred L. Drake, Jr. fred at zope.com Zope Corporation ___ 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] TAL Hotfix 2004-07-14 for Zope 2.7.0, 2.7.1
This hotfix product fixes a security bug in Page Templates. This fix ensures that values substituted in named slots in translated elements are properly encoded. If encoding is not desired and the source of the replacement text is trusted, the structure modifier can be used with the tal:content or tal:replace attribute to explicitly disable encoding. Affected Versions This fix applies to Zope 2.7.0 and 2.7.1. Zope versions 2.7.2 and newer already contain this fix, and do not require this hotfix. This fix also obsoletes 'Hotfix_20040713', so that should be uninstalled when this hotfix is installed. See the README.txt file provided with 'Hotfix_20040713' for instructions on removing that hotfix. Getting the Hotfix You can download the hotfix at: http://zope.org/Products/Zope/Hotfix_2004-07-14/Zope%202.7.0%20-%202.7.1/ The product contains a README.txt file with installation instructions. -Fred -- Fred L. Drake, Jr. fred at zope.com Zope Corporation ___ 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] Troubles with hotfix20040714
On Mon, 19 Jul 2004 09:48:00 -0700 (PDT), C. Olmsted [EMAIL PROTECTED] wrote: Not sure if this is quite the correct list to post to, but I'm having trouble with Hotfix20040714. We're running zope 2.7, plone 2.0.3, and zwiki 0.32.0. Can you test with the 2.7.2 release candidate? This very much sounds similar, but all occurances of TAL_VERSION in the Zope 2.7.0 and 2.7.1 sources are corrected in the 20040714 hotfix. The only ways I can think of to trigger this problem with the hotfix installed is to import compile templates containing macros before the hotfix is loaded during product initialization (reasonably possible), or for someone else to import TAL_VERSION before the hotfix is loaded and generate TAL bytecode themselves (highly unlikely!). It would be interesting to know if the macros are from a PageTemplateFile instance. -Fred -- Fred L. Drake, Jr.fdrake at gmail.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] Troubles with hotfix20040714
On Tue, 20 Jul 2004 10:40:22 -0700 (PDT), Cliff O. [EMAIL PROTECTED] wrote: Ok, so I just finished loading up 2.7.2rc1 and all seems well using the same products and database as before. I can probably migrate the site once 2.7.2 final is released but, of course, it would be great to apply the hotfix in the meantime. Unfortunately, I don't think making the hotfix any better is going to be easy; it's still a product which is initialized after some of the affected code has been loaded and possibly used. Since 2.7.2 should be coming out very soon, I'm not sure it's worth the additional effort to elaborate the fix any further. I'll ask around here at ZC to be sure; others may disagree with me. Andreas: Do you have a date for the 2.7.2 final release? -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Re: [Zope-Coders] Collector Status Meanings
On Fri, 30 Jul 2004 11:50:57 -0400 (EDT), Ken Manheimer [EMAIL PROTECTED] wrote: Accepted: Issues that some supporter(s) has responsibility for resolving it, and it is not yet resolved. Your description says that some supporter has assessed the issue as warranting repair, and later says that the the issue has an assigned supporter. I think it's a lot clearer to directly say that an accepted issue has a supporter responsible for resolving it. I don't think it makes sense to use this to indicate a supporter (and possibly some of their time) has been allocated to deal with the issue; the list of assigned supporters should be sufficient for that. If the list is empty, no supporter has been assigned. I think Accepted should be used to indicate that the issue is real and still needs to be addressed in some way. This is independent of assigning it to one or more specific supporters. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] ZConfig keys
On Wed, 04 Aug 2004 10:24:30 +0200, Godefroid Chapelle [EMAIL PROTECTED] wrote: I would like to confirm that ZConfig keys are case insensitive and that the corresponding attributes on the config object returned by the 'loadConfig' call are always lower case. It sounds like I need to clarify the documentation a bit. ZConfig schema allow you to change the case-sensitivity by changing the keytype of the schema or of a sectiontype. If you don't use this feature, the basic-key type is used, which converts to lower case. The effect is case-insensitivity for the keys. The attributes on the configuration objects, both for the top-level schema and individual sections, are computed by taking the key (after conversion by the keytype) and replacing hyphens with underscores. So a key of My-Key is the same as my-key, and the attribute name will be my_key. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] ZPT Optimization Opportunity
On Mon, 27 Sep 2004 14:18:30 -0400, Tres Seaver [EMAIL PROTECTED] wrote: Transformation is already complete at that point. The only difference is the type of the result returned (eventually) to the publisher. Ok, that sounds good. BTW, I looked again at where StringIO is used, and it seems that ZPT constructs extra StringIO objects for (at least some) nested blocks. In that case, we might be able to extend the win by having the calling bit use 'list.extend' for its own buflist, instead of calling 'getvalue'. That shouldn't be hard to do neatly, and seems an easy win. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Re: inconsistent mimetype assignment for uploaded files
On Tue, 05 Oct 2004 12:44:32 +0200, Tino Wildenhain [EMAIL PROTECTED] wrote: Well, the problem might be the asymptation part of the filename should be considered an indicator of its contents. That is a nuissance. It's unfortunate we still don't have any sort of common type system for bytestreams that's supported in filesystems. But disk files aren't the only source of bytestreams, so that doesn't necessarily help us in the end. Arent there any libs for python to examine the contents (usually the first few bytes) for the type of the file? I'm not aware of any for the general case. There are a few things like the imghdr module, but those are not for arbitrary files, and likely aren't sufficiently capable. I think there's a library from the Gnome desktop project for this (basically providing something like the Unix file command), but I don't know if there's a Python wrapper for the library, or an all-Python re-implementation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Re: Conditional imports in ZTUtils/__init__.py
On Tue, 05 Oct 2004 09:47:11 -0500, Evan Simpson [EMAIL PROTECTED] wrote: This is part of my attempt to allow the various bits of ZPT to work outside of Zope. It assumes that the presence of the 'Zope' module is a reliable test. Perhaps this is a YAGNI, or perhaps there's a better way of accomodating non-Zope users. I've been recommending people wanting to use page templates outside of Zope use the version from Zope 3. I've not had time to follow-up with the people that have been experimenting with it, though. The code in ZTUtils' __init__.py is scary, partly because of the import-order issue. If the condition should remain at all, it should be implemented using the usual pattern:: try: import Zope except ImportError: # extra stuff goes here ... The assignments could be made non-conditional without introducing problems, so they should be. I'm not sure what the intent of the additional imports is; that seems very strange since there's no alternative implementation if the Zope package hasn't been imported. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] PageTemplate XML mode bugs
On Tue, 05 Oct 2004 12:47:33 +0200, yuppie [EMAIL PROTECTED] wrote: There are two annoying bugs that make the XML mode unusable for many tasks: - http://collector.zope.org/Zope/1101 (i18n namespace broken) - http://collector.zope.org/Zope/1474 (XML files opened in binary mode) I would volunteer to work on these issues, but for that it would be useful to know: 1.) Does anybody feel responsible for the TAL or PageTemplates module? I try to pay attention to TAL and PageTemplates issues, but don't always have time to deal with them, or answers regarding what *should* be done. Many of the issues have to do with the expectations of others not aligning with my own. ;-) 2.) What was the motivation for the original code? #1101 looks like someone just forgot to remove a debug assert in TALParser.py. The Zope3 version doesn't have that assert statement. Or was there a reason to disable i18n for XML mode? That's what it looks like. The assert isn't in the Zope 3 version of the code. I suspect it can be safely removed. I've made a note of this in the tracker issue. #1474 is a change backported from Zope3. It was reverted for HTML mode for apparently the same reason why the XML mode is still broken. I guess the motivation was to preserve CDATA, but I don't know that for sure. This report isn't clear. Please update the issue and explain what the problem is; glancing at the code on the Zope 2 and Zope 3 trunks, the only thing that looks suspicious to me is that re-opening an HTML file doesn't use Python's universal newline support. HTML is always text, so should be treated that way on input. XML may contain textual content, but should always be handed to the XML parser as a raw byte stream to allow the proper decoding machinery a shot at doing the right thing. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Re: PageTemplate XML mode bugs
On Tue, 05 Oct 2004 18:44:04 +0200, yuppie [EMAIL PROTECTED] wrote: Ok. I'll remove that line in CVS/SVN. Thanks! I added a new comment to the issue. Hope that makes things clearer. ( http://collector.zope.org/Zope/1474 ) Ok; let's just say the discussion's moved there. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Python2.4 and Zope 2.7
On Sun, 17 Oct 2004 18:43:34 +0200, Andreas Jung [EMAIL PROTECTED] wrote: Python 2.4 is still in alpha stage and there are no plans to support Python 2.4 in the short term. It's in beta as of Friday evening; this would be a good time for someone with time to start testing it with various Zope branches (2.7, 2.8/trunk, X3 3.0, X3 trunk). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Python2.4 and Zope 2.7
On Mon, 18 Oct 2004 06:59:26 +0200, Andreas Jung [EMAIL PROTECTED] wrote: Zope 2.7.3 + Python 2.4 fails when running the unittests: Then a collector item should be filed. ;-) I don't know anything about ThreadedAsync myself. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Proposed changes to the TAL specification
I'm proposing some (small) changes to the TAL specification. This would result in a new version of TAL for Zope X3 3.1 (and Zope 2.8 if anyone wants to backport the relevant code changes). The discussion will be on the ZPT list, where I've sent a copy of the proposal. The proposal is also located in the ZPT wiki at: http://zope.org/Wikis/DevSite/Projects/ZPT/RemoveInsaneConstructs If you're interested in these changes, please discuss them on the ZPT list. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] ZopeInterface
On Thu, 28 Oct 2004 11:07:52 +0200, Radoslaw Stachowiak [EMAIL PROTECTED] wrote: Could anyone please provide me information when ZopeInterface product is going to be updated ? And how is it related to zopex3 releases ? I'm planning to release a final version around the time that Zope X3 3.0.0 final is released. I'm gentoo linux (www.gentoo.org) developer maintaing all zope related packages, and we are considering inclusion of ZopeInterface as separate package (we already have zopex3_rc3). Excellent! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ 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] Renamed the Zope package to Zope2 and including Zope 3 packages in Zope 2.8
On Mon, 31 Jan 2005 19:25:15 +0100, Lennart Regebro [EMAIL PROTECTED] wrote: Note that diskussions about the Zope2 + Zope3 pagetemplate issue arrived in the conclusion that, the faster we can get Zope3 pagetemplates back ported to Zope2, the happier we will be. ;) I have no idea if that is a big task or not. That's not my recollection. :-( My goal is that the various packages involved in page template in Zope 2 become facades over the Zope 3 implementation. I'm afraid I've not had any time to work on this; I'm hoping I can spend some time Wednesday evening, though I'm also approaching an important release for Expat. This is all volunteer time. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] ZConfig issue: products and container-class
On Mon, 14 Feb 2005 15:22:38 -0200, Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: It's obvious that the container-class directive is being evaluated much earlier than the products directive. Without delving further into the code, it looks like the container-class directive has an error checking built right into the directive type that tries to import the assigned class, while the products direcive will only be made effective AFTER all ZConfig configuration has been processed... This is a known limitation. You can avoid it by using the PYTHONPATH environment variable instead. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] ZConfig issue: products and container-class
On Mon, 14 Feb 2005 18:41:20 -0200, Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: Should I bother with the collector entry or is it a known limitation no one is going to bother with? :-) It's not a bad idea to file a report in the collector. While I've no plan to change it myself, that's more a matter of being busy on other things. I think the right thing to do for the fix is to make dotted names get resolved later, but that requires changes in serveral places. And it must really be done in the environment, instead of with the path directive, as that is also evaluated too late in the process... That's right. The path and product configuration values are very similar. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Parrot
On Mon, 21 Mar 2005 10:54:11 -0500, Andrew Langmead [EMAIL PROTECTED] wrote: I haven't tried the latest version of Parrot, but I'd think that Zope would be the last thing that will run successfully. I don't know that Parrot tries to emulate Python's C API either, and Zope definately contains several C extensions. These would need to be re-written in Python or to use Parrot's API. So I suspect there's a good bit of work to do to really make it run. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: ZConfig change breaks Zope 2 and Zope 3
On 5/9/05, yuppie [EMAIL PROTECTED] wrote: But I still believe it was wrong to change the 'inet_address' datatype in ZConfig. I spoke with Tim about this briefly today, and I can't remember the reasons for some of the relevant changes. I suspect at this point that putting less magic in the ZConfig type is probably the right thing; much of the remaining magic should be able to disappear at that point. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [Zope-Coders] Zope 2.8 coming this weekend
On 6/10/05, Paul Winkler [EMAIL PROTECTED] wrote: Mind if I check in text-only changes to the 2_8 branch? It's still Friday for Andreas, so this is a good time! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [Zope-Coders] Zope 2.8 coming this weekend
On Fri, Jun 10, 2005 at 02:21:32PM -0400, Paul Winkler wrote: Done. Like I said, just trivial docs typos. Yeah, but improvements are improvements! On 6/10/05, Paul Winkler [EMAIL PROTECTED] wrote: While I'm at it, anybody object to the attached patch to doc/FAQ.txt ? I don't see a need to include the disclaimer about Python 2.4; I test on 2.4, and use Zope 3 trunk with 2.4.1 all the time. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Extending Zope's ZConfig Schema in a Product?
On 6/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: Gosh, that looks too nice to be true. I will try that out tomorrow and write out a how-to on zope.org if it works out. It is too good to be true; sorry. Well, it is true, but it's not what you're looking for. You can't use it to extend the schema for Zope. You can use it to add new concrete implementations for things that are allowed; the original use-case was to allow things like new kinds of storage for the database. I've spent a little time thinking about this issue, and have come up with at least one way to deal with it (and %import would be used, in part), but I've never been completely happy with the approaches. Since using an additional configuration file is possible (and quite easy in Zope 2, since the location of the instance is so easy to discern, I'm not convinced it's actually important to support embedding the configuration for 3rd-party components into zope.conf. If you want something you can use now, using a product-specific configuration file, with an appropriate schema, will do quite well. It also doesn't require hacking (or monkey-patching) Zope or ZConfig, so it would be easy to deploy in a variety of situations. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Extending Zope's ZConfig Schema in a Product?
On 7/1/05, Chris McDonough [EMAIL PROTECTED] wrote: FWIW, I don't know if it helps at all, but there's a concrete example of allowing a 3rd-party product to add a section to zope.conf via %import in the ClockServer product at http://www.plope.com/software/ClockServer/ . It sounds from your description exactly like what you want to do, although it adds a section rather than just a key, which might be fine for your case. I'll note what you didn't. ;-) This works for ClockServer because you're adding a server type, and those are already allowed in the Zope configuration. This doesn't cover the case of a section that isn't an implementation of an abstract section type already accepted by the Zope configuration (log handlers, servers, databases, storages... that's all I can remember off the top of my head). The general case of being able to add a section (or anything else) isn't covered by the current implementation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Extending Zope's ZConfig Schema in a Product?
On 7/1/05, Jens Vagelpohl [EMAIL PROTECTED] wrote: That just has the disadvantage that you're increasing the number of configuration files to maintain in an instance. If it's imported and used in zope.conf at leaast there's just one file to deal with... This is true. Is that really important, though? Adding this ability would be a new feature, so not available until 2.9. I got the impression people want to do this now. It makes a lot more sense to pick something that can be used both now and into the future than hack something together. If someone wants to create a way to manage product-specific configurations in a single file, it's not hard to create a Python package to support that, and products that want to have their configuration placed in that file could set themselves up to use %import in that file. I've no need of that myself, but others are certainly welcome to create such a package; it may be a reasonable addition for 2.9, and could be distributed separately for use with 2.7/2.8. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Build process for Zope 2.9
Hey all, I'm working on a revised build process for Zope 2.9, based on the work that we've done for Zope 3. What this means is that we'll have a setup.py that uses the code from zpkg (http://www.zope.org/Members/fdrake/zpkgtools/) to load metadata from the various packages are part of the checkout, and use distutils to perform the build. One thing that will need to change is the makefile that gets generated by the configure script. The current makefile has an enormous number of options that don't really seem to make sense, and many targets. I'd like to remove any that aren't being actively used, but it's hard to tell which those are. Would anyone object if we switch to something a lot closer to the Zope 3 makefile? There's basically in-place builds and tests, and that's it. Everything else is handled outside the makefile. Comments or objections? -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Can't fetch externals???
On 9/30/05, Paul Winkler [EMAIL PROTECTED] wrote: One thing Tino suggested: it might be a firewall issue. Does svn's externals-fetching look somehow different to a firewall than does a regular (non-external) checkout? When I tried checking out on my laptop, I noticed that ZoneAlarm asked 'me if I wanted to allow svn.exe to use the internet at exactly the moment that it was time to fetch the externals. Weird - doesn't it still use ssh? What's different? Tino's on the right track; the externals do NOT use ssh; they use an unauthenticated connection and cannot be used to commit changes (by intent). So it could be a firewall issue; some different port needs to be opened. The Subversion documentation should tell you what's needed. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Can't fetch externals???
On 9/30/05, Paul Winkler [EMAIL PROTECTED] wrote: Hypothesis: Is it possible that svn.zope.org is configured such that when you get the externals, it uses plain svn (i.e. an anonymous checkout) rather than svn+ssh? As noted, very likely. The default port for SVN w/out SSH is 3690: http://svnbook.red-bean.com/en/1.1/ch06s03.html -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Mountpoints
[It doesn't look like my response went to the zope-dev list; re-sending.] On Tuesday 18 October 2005 15:43, Tim Peters wrote: I'm copying Fred because he may remember more about this than I do. Fred, do you know of a reason why I can't stitch a newer ZODB into Zope(2) trunk? I have a dim, fading memory of the last attempt failing, and of agreeing in email to wait for the 5 guys to do something before trying again. Sorry for not being more specific ... We need to do the zpkg/ZODB switch all at once because it affects how extensions get their include files. When I tried switching the Zope 2 trunk before, there was a problem due to Five tests failing. I don't remember the details, but the Five-folks seemed to think things would be better with newer versions of Five. Since Five development is done elsewhere, though, it's hard to tell what the deal is with that. I snapshotted what I did get done as the zpkg-build-branch, so we can get back to it without duplicating work. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Society attacks early, when the individual is helpless. --B.F. Skinner ___ Zope-Dev maillist - Zope-Dev@zope.org 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: Get rid of configure/make? (was Re: [Zope-dev] Re: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:)
On 11/5/05, Tino Wildenhain [EMAIL PROTECTED] wrote: The usual setup.py from distutils to make it more pythonic. The install.py in the root of the distribution is actually a conventional setup.py. Would it be helpful to keep the setup.py name? We renamed it to encourage the configure/make dance, but that doesn't seem particularly helpful to me. (It would also simplify the zpkg implementation just a tiny bit to use the setup.py. name.) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Society attacks early, when the individual is helpless. --B.F. Skinner ___ Zope-Dev maillist - Zope-Dev@zope.org 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: Get rid of configure/make? (was Re: [Zope-dev] Re: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:)
On 11/5/05, Jim Fulton [EMAIL PROTECTED] wrote: It's main benefit is that it leverages a familiar pattern, but I'm not convinced that it's worth it. Also, as tools like rpm and deb become more widely used, I'm not sure how familar the configure/make dance is. Other than Python and Zope, I never use configure/make anymore. I think more and more people never have to build from source. There's little I build from source these days, and I'm generally happy to build myself. I think the only things I build are things I'm actually contributing to myself, whether it be for work or volunteering on open source projects. I don't even build my own TeX tools any more. :-) Also, configure/make is only familiar in the Unix world; most installations appearantly are on Windows boxes using the binary installer. The importance of the familiar dance just isn't very significant any more. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Society attacks early, when the individual is helpless. --B.F. Skinner ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Not-really-unit-testing ideas.
On 11/23/05, Lennart Regebro [EMAIL PROTECTED] wrote: Basically, I'd like to create a site once, and use it for all subsequent tests, until I made a change that means the site needs to be recreated. But how? Well, I'm not sure. How, for example, could I Jim's new test runner includes support for layers, which solves this issue. I think the Zope 2 trunk is already using the new test runner; you can also use it on the Zope 3 trunk. We're using test layers extensively here, and it really helps. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On 11/23/05, Stephan Richter [EMAIL PROTECTED] wrote: Using this group, we have about an 80-90% -1 vote count. I'll weigh in with a -1 as well, for all the reasons cited by the other -1 voters on this issue. Zope 2 and Zope 3 are far too different at this point. The only way I see for convergence to be a good thing is for Zope 2 to be essentially skin and configuration on top of Zope 3; I really don't want to end up with Zope 2. Jim's vision is strongly for convergence, and I'm sure he'll say that himself when he's back (he's away for a few days). I don't pretend to know what he'll say about this idea, though. I don't *think* he think's it's time, but he doesn't like people predicting what he'll say. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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.conf extensibility
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: I have some product that would greatly benefit from being able to be configured from within zope.conf. I don't want a separate configuration file. Period. Tres Seaver and I implemented this during the Goldegg sprint in Fredericksburg, which we provided a location for. This should be in Zope 2.9. I don't know that there's any real documentation for this. Feel free to add some. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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.conf extensibility
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote: I haven't seen this being checked in at all, maybe it's in Tres laptop? These were committed to the trunk before the 2.9 branch was created: r39652 | tseaver | 2005-10-26 15:10:40 -0400 (Wed, 26 Oct 2005) | 1 line Allow custom section types to play in product-config. r39635 | tseaver | 2005-10-26 12:09:59 -0400 (Wed, 26 Oct 2005) | 7 lines Added a 'product-config' section type to zope.conf, allowing arbitrary key-value mappings. Products can look for such confgiurations to set product-specific options (see the example 'product-config' section in skel/etc/zope.conf.in for sample usage). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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.conf extensibility
On 12/1/05, Chris Withers [EMAIL PROTECTED] wrote: In this case, I think zopeschema.xml should be documentation enough, especially as any product author wanting to use this feature is going to have to write a component.xml at least ;-) Actually, a product author isn't required to write a component.xml, though they probably should for anything interesting. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: Unit Test Failures
On 12/19/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Now I see what you mean by contract. You're right, I guess it isn't documented then, but perhaps it should be. That's never been part of the contract and, as Tres notes, it's inconsistent. The implmentation will only sort when it uses the multi-line representation of the dict, not the single-line form. I don't oppose adding this to the contract and fixing it for the single-line representation for Python 2.5, but I'd rather think more about what the right interface is between displayed objects and the formatter. This is where a component architecture would really come in handy in the standard library. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] What use cases are driving make install from a checkout?
On 12/21/05, Leonardo Rochael Almeida [EMAIL PROTECTED] wrote: My point is: I don't think there's anything wrong in the install procedure being different between the checkout and the tarball, but it should never take more than a couple of fixed (and documented) steps to convert a checkout to a tarball-equivalent environment, where ./configure; make; make install would work. How important is the convert aspect of this? Would creating a new tree that supports ./configure; make; make install seem reasonable to you? If so, zpkg -t -C releases/Zope.cfg would create the tree, and cd Zope-0.0.0 would make that the current directory. There is a hidden difference here, however: the new tree would be a Zope 3 release, and would not typically contain everything in the checkout. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: Product installation (implicit vs. explicit)
On 12/22/05, Andreas Jung [EMAIL PROTECTED] wrote: Jar files have no dependencies. Well, I know you know what you mean here, but I'll elaborate since the kids haven't started fighting yet this morning. :-) Jar files don't have dependency metadata. They're pretty much equivalent to zipped Python libraries. Python Eggs take the next step by adding the dependency information and other interesting bits in the support infrastructure. I'm sure there's a Java equivalent (or several), but I've not heard of it. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: zLOG module deprecated
On 1/9/06, Andreas Jung [EMAIL PROTECTED] wrote: ZODB defines these levels but I can not see any code in the ZODB package that actually uses these levels. Nobody should be using the zLOG levels with the logging package, but rather use the logging package levels. So in the end, there's no need for Zope to be defining levels at all, only conventions for how the levels are used. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: zLOG module deprecated
On 1/9/06, Florent Guillaume [EMAIL PROTECTED] wrote: My point is that the python logging levels are insufficiently fine grained. The python logging framework leaves room for numeric levels and registering equivalent strings, and indeed ZODB and zLOG have them defined. I want to use them. Do you need someone else to define a constant for the level you want before you can use them? There's a API in the logging module that allows you to pass the desired level in. I see no reason to require a constant to be defined outside your code. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: ZPT backward compatibility
On 1/17/06, Tino Wildenhain [EMAIL PROTECTED] wrote: Add to it the fact the zpt@zope.org was due to be retired anyway ;) Though retirement for the list was discussed, it was decided not to retire it since it was still the best place for implementors to discuss matters. The implementations in Zope 2 and Zope 3 are not the only implementations, and the other implementors are justifiably not interested in joining Zope-specific lists. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [Zope3-dev] December release post-mortem
On 1/18/06, Jim Fulton [EMAIL PROTECTED] wrote: If eggs work out, as I hope they will, I'd like to stop work on zpkg and just use eggs. +42 -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [Zope3-dev] merge zope-dev and zope3-dev?
On 2/16/06, Chris Withers [EMAIL PROTECTED] wrote: To be clear: I'm talking _only_ about merging the dev lists, _not_ the user lists. The users lists are still largely independent, but it seems like just about every post to the dev list now has a bearing on both Zope 2 and Zope 3, especially as they become closer and closers... -1 -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org 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: XML export/import is cool! (Was Re: [Zope-dev] Deprecating XML export/import?)
On 3/24/06, Jim Fulton [EMAIL PROTECTED] wrote: We've had sucess writing XSLT templates to transform the pickle data into formats easily parsable for particular applications. As part of a recent task (likely the same one Jim's referring to here!), I transformed the XML export into another XML pickle, but for a simpler data structure that could be unpickled without dealing with the application classes. The CDATA marked sections that held the templates aren't useful for XML tools, but they do make it somewhat easier to read the pickles directly (valuable when trying to figure out what a transform is starting from!). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ Zope-Dev maillist - Zope-Dev@zope.org 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] 64-bit BTrees
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I welcome comments. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [ZODB-Dev] Re: [Zope-dev] Re: 64-bit BTrees
On 4/17/06, Jim Fulton [EMAIL PROTECTED] wrote: The fact that IIBTrees is so widely used is exatly the reason I want to use 64-bits for the existing types rather than having to introduce a new type. Oops, I was checking in the separated version of 64-bit BTrees while this was landing in my inbox. ;-/ Once we determine which approach we're going with, I should make an alpha release of ZODB 3.7 and knit that into the Zope 3 trunk so we can get more testing in context. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ Zope-Dev maillist - Zope-Dev@zope.org 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: 64-bit BTrees
On 4/13/06, Fred Drake [EMAIL PROTECTED] wrote: I've created a feature development branch for this, and checked in my initial implementation. I've made another branch for this, with a different twist. I'm not sure it'll be interesting, but I think it'll solve my immediate need until I can get around to reasonable testing of the performance implications. The fdrake-optional-64bits branch will compile using the C int type for I keys and values by default, and using the PY_LONG_LONG type if ZODB_64BIT_INTS is defined. This allows 64-bit BTrees by building ZODB like this: python setup.py build_ext -D ZODB_64BIT_INTS build BTrees.IIBTree.using64bits will be True if ZODB_64BIT_INTS is used. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zpkg, building zope from source
On 5/15/06, Sidnei da Silva [EMAIL PROTECTED] wrote: Also on a similar subject, running 'make install' from a checkout only copies packages that have a 'SETUP.cfg' inside. Is that intentional? I thought someone was in charge of fixing the 'make install' dance. Someone might be, and it might even be me (I don't recall). There's been no time for me to work on that, and I don't foresee any in the near future. You're welcome to look into this yourself. I've not been convinced that this is actually an important use case. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Education is hanging around until you've caught on. -- Robert Frost ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zpkg, building zope from source
On 5/15/06, Sidnei da Silva [EMAIL PROTECTED] wrote: I was looking at zpkg for the first time today, and was sorry to realize it won't run to completion on a Windows machine due to some minor use of os.WIFEXITED which is due to a dubious use of the 'tar' command, since Python has a 'tarfile' module in the standard library. Since it looks like using tarfile there should work just fine, would anyone mind if I replace this? You're welcome to change it if the external behavior doesn't change. That would make the whole thing easier to use on Windows, which is only slightly objectionable. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Education is hanging around until you've caught on. -- Robert Frost ___ Zope-Dev maillist - Zope-Dev@zope.org 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: [Zope3-dev] pkg_resources or pkgutil?
On 5/25/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I think they do pretty much the same thing (but I could be mistaken). Are they interchangeable? If not, are they compatible so that we just add both ways to both files? If they're not compatible, which one should we use in the future? Looks like no one bothered to answer this. :-( No, they aren't equivalent. The pkg_resources flavor is only effective if pkg_resources is available; I don't think that should be assumed. The pkgutil.extend_path version should be used as the fallback when pkg_resources is not available. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Next step on Blobs?
On 12/17/06, Christian Theune [EMAIL PROTECTED] wrote: Nope, not yet. I don't have any plans for Zope 2, but I'll be working on the Zope 3 side. ... - Make the existing File implementation use blobs This would be good so people see how to use them and get blobs widely exposed. Ideally, the Zope beta releases would uncover problems with existing applications/installations. There's more than one of these. zope.file was intended to use blobs when they come along, so I'd suggest that making that support blobs directly, with backward compatibility for the existing structure, is the right way to go. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Next step on Blobs?
On 12/18/06, Christian Theune [EMAIL PROTECTED] wrote: a) provide a generation to convert old data structures Since we tend to work with high-availability issues at ZC, I'm hesitant to go this route; expensive generations that affect large portions of a database can be very difficult to run without a significant maintenance window. For things like this that can affect a large number of objects that otherwise wouldn't be written to, I'm generally in favor of avoiding modifying the object and making the code compatible with the old data structures. Yes, this carries it's own risk (failure to be compatible) and cost (maintaining support for the old structures), but that can be mitigated through tests. b) keep the existing interfaces working I suspect this will be easy with zope.file, since it was specifically designed to work with blobs. The interface doesn't lend itself to having reasonable security declarations declared through ZCML (since the open() method is used for both read and write access), but that's a different failing (which I'd be happy to see fixed with an improved interface). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: [Zope] Re: [Warning] Zope 3 component architecture (CA) not reliably usable for registrations from Python
On 1/10/07, Dieter Maurer [EMAIL PROTECTED] wrote: *It* must be informed whenever it is used in a different thread. Perhaps it could use some thread-local data to keep track of this? threading.local comes to mind. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope-Dev maillist - Zope-Dev@zope.org 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] difference between OOSet and OOTreeSet?
On 3/1/07, Martin Aspeli [EMAIL PROTECTED] wrote: Sets may turn out to be *sorted* if they're implemented with trees, but I don't think the implementation promises that either. The BTrees implementation definitely does promise the sorting relationship for the results of iteration, which is useful. Python's built-in set types do not make that promise (and they happen to be hash-based). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Launchpad Janitor?
On 10/15/07, Chris Withers [EMAIL PROTECTED] wrote: I'm pretty sure automated bug expiry is a very bad thing. Agreed; it's completely unhelpful. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zcml entry points
On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: zcml entry points
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. Slugs are evil; agreed. We never use them. They were an accident of the instance tree inherited from older versions of Zope, and how that tree was re-interpreted for Zope 3. They never worked well, and did no one any favors. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I actually really like this; I don't get the configuration for a package unless I ask for it. It's not unusual to want only the code and not the default configuration for a package. If we had entry points, we could just load the egg. Internally, oi.plum may use include / as much as necessary to load *its* dependencies, but that's not something the user of the package needs to worry about. Requiring a package doesn't say anything about how it's going to be used; making an assumption about that is really bad. If Zope loaded entry-point ZCML automatically (maybe with an on/off switch in zope.conf for those who need more fine grained control) that'd be a pretty nice solution. I suspect I'd always want it off. Picking up configuration willy-nilly is too dangerous. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Re: zcml entry points
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a It sounds like your concerns center around users of a pluggable/extensible application (like Plone), rather than being general Zope concerns. It's certainly reasonable for an application to want a plugin architecture that works that way. Perhaps the development teams for the applications would be interested in getting together and sharing a package that supports a plugin architecture that works that way. That would be a good place to share effort without negatively impacting users who need bare-metal Zope or the developers of applications that don't have similar plugin-management requirements. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org 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] zc.buildout installing parts not asked for
On 10/27/07, TIm Terlegård [EMAIL PROTECTED] wrote:
When using zc.buildout I discovered that it installed a part that I
didn't
specify in the 'parts' option. This happened because I referenced this
part somewhere else. Is this how it's supposed to be? I would prefer
if it
only installs the parts I specify in parts. I don't see anything
wrong with
reusing options from a part that I don't necessarily want to install.
When a part refers to another part via ${...} variable expansion, a
dependency between parts is established. If you don't want a
dependency, move the setting into a separate section (with no recipe
setting) and reference that from both parts that need the setting.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
