Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
Leonardo Rochael Almeida writes: Funny, with all the talk about 2.8 including only the ZODB work and fixes, I thought we'd have a 2.8 branch by now... :-) Yeah, we're kind of call that the trunk for now, so we pick up the general bug fixes as well. Too many actual (active) branches makes for true pain in managing patches. -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] tcp port not 8080
ben strawbridge writes: I just installed zope and plone. It works fine and I can access the management console for it. The problem is I am running tomcat on this box as well and it is already using port 8080. I seaerched around the zope and plone sites but can't find anything about where to change this, except for references that it can be done. I also googled some terms to no avail. It can indeed be changed. The recommended way to do so depends on the version of Zope you're using. Which version is 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] CVS Head: Error Value: iterable argument required when adding objects
Jeremy Hylton writes: Where is that documentation? I'm not able to find it. There used to be a couple of .txt files for this, but I don't remember where. ;-( -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] [ZConfig] wishlist
Dieter Maurer writes: It uses top level keys for configuration. Sigh. We should change that. But anyway (even if session configuration were encapsulated in its own section), I would need to change the Zope schema (if I understand ZConfig correctly, which is not yet sure). That depends on how we do it. We could easily make an abstract section type (think interface), and the current session machinery and your custom machinery could both implement that. Each would define a section type that implements that interface, and the resulting configuration object would be a factory for the session manager. (This is how log handlers are done.) Ideally, I would like to be able to combine schemas from schema components -- say: use the standard Zope schema and apply the following additions/changes. If we used an abstract section type for a session manager, the Zope schema would require the abstract type; loading the additional schema component would be a matter of adding a %import line in the configuration file. Thus, all my wishes are already addressed by the current ZConfig :-) Glad to hear it! There are probably changes we'll want to make to the shape of the actual Zope configuration (like moving the session management configuration to a section with an abstract type); input like yours is very valuable in this area. Thanks! -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] [ZConfig] wishlist
Chris McDonough writes: In a perfect world, it would be possible to extend or change the main section of a schema (or any section in a schema) with altnerate keys or sections, I think. I have no idea how to do it, though. Phillip Eby and I discussed the override issue a bit, and decided that it wouldn't be too hard to do, but we had no concrete need. Adding keys and sections is easy with Phillip's schema extends='...' support. These ideas all revolve around creating new schemas, though, so aren't quite what we've done with Zope itself. We can already create new implementations of abstract types and load them through %import in specific configurations; this only applies to sections, though. I suspect the current support is pretty much what we're looking for; if we're forced to describe things as components in the configuration, we'll be forced to deal with them as components in the implementation. I expect this will lead to better understood implementations, as each piece is more easily understood in isolation, and more readily maintained. -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] ZConfig: a wish list
Barry Warsaw writes: I suppose that model precludes even access to %define variables after parsing. That's right. If you really want to control the structure of the pat specifications, you need to deal with it explicitly; create a setting to control the base directory, and then use os.path.join() to deal with paths relative to that base. My usual response has been that it can already be done reasonably using something like: %define topdir /some/path/to/the/top/of/my/tree %define logdir $topdir/log some-logfile $logdir/interesting.log other-logfile $logdir/another.log Which is essentially what I do now. Have your users complained that it's too much? That's the primary motivation, for sure. The idea is that if ZConfig is going to be the configuration language that Mailman3 site admins use, I'd like to reduce to a minimum the number of options or lines of files they need to look at, decide about, and change. If they can simply define a basedir and have all the defaults be defined in terms of that, it would be a bonus. I don't know enough about Mailman3 configuration to know how what's being done in the config file or how many decisions the site admin needs to deal with. Is there something for each list? I'm not sure it's useful, but the style of the schemas I've been writing make all that extra stuff kind of redundant. I actually depend on the type and attribute names being the same because of the way I dig values out when I post-process stuff in Python. This sounds very strange to me. Perhaps we should take a look at it when we're in the same town tomorrow. -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] [ZConfig] wishlist
Dieter Maurer writes: Today, I incorporated our Zope extensions into Zope 2.7 and had to determine how I can provide the necessary configuration through ZConfig. I feel the configuration process is not yet as modular as it should be? There's certainly room for improvement. Let's explain what extensions I have: 1. an alternate Transience implementation for Zope sessions I don't know how the session machinery works in Zope; if there's a section to configure that at all, it should at least be easy to make it possible to provide an alternate section type that can be used. What changes did you need to make to Zope to make this configurable? 2. a new log handler rotated_logfile (which performs automatic daily rotation with log files named prefix.date) This doesn't need any changes in zLOG; you should be able to provide a new component and use %import to load it in the configuration. 3. a common piece of configuration used for communication between Zope and a checkZope process (which supervises that Zope responds sufficiently fast) I solved 1 and 2 by rudely modifying Zope sources (zLOG/component.xml and associated handlers, Zope/Startup/zopeschema.xml and associated handlers). I do not yet have a solution for 3 but I probably will give the checkZope process the complete Zope schema and configuration file. I'm not sure why you want the checkZope process to load Zope's configuration at all. Can't you just use a separate configuration file? If there are portions that need to be shared, you can place those in a separate file and %include that into the Zope and checkZope configurations. Almost surely, it would not have been necessary to modify the zLOG configuration to get a rotated_logfile because components and sectiontypes provide enough modularity. Yup. However, schemas and configuration files seem not to be modular. Not terribly, no. That wasn't a requirement that anyone made me away of at the time. Bits of configuration files can be stored in separate files and composed using %include. I would like to compose schemas and configuration files from components: e.g. combine the standard Zope schema and a small schema for our extensions to form the schema used by the extended Zope, combine the configuration file from long living Zope settings (maintained in CVS), instance specific Zope settings (locally maintained) and configuration fragments used by Zope and other components (e.g. the checkZope process). One approach we've taken on some projects is to place all settings within sections, leaving the top-level as a place to put the sections. This wasn't done for the main Zope schema due to various forces; perhaps that was a mistake. I think, a general include function for schemas (including not only types but complete schemas) and configuration files could provide this kind of modularity. Have you looked at the schema extends=... support Phillip Eby added? -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] ZConfig: Keytype and section type extension
Barry Warsaw writes: Since I didn't understand what keytype actually provided, even after reading the docs on it several times, I've never found a need for it wink. Sounds like I need to improve the docs for this. Changing the keytype allows different interpretations for keys. The only thing required of keys at the lowest level of the parser is that keys do not contain spaces. The basic-key datatype is used to create a case-insensitive handling to keys. Setting keytype to identifier would require that all keys in sections of that type be Python identifiers, and would be case-sensitive. Another keytype might allow email addresses to be used as keys: def email_address(text): user, host = text.split(@) host = host.lower() # normalize what can be normalized return [EMAIL PROTECTED] % (user, host) This can be especially useful when implementing a section type that acts as a mapping: sectiontype name=email-mapping keytype=mypkg.datatypes.email_address datatype=mypkg.datatypes.mapping key name=+ attribute=mapping/ /sectiontype where the additional datatype simply discards the section object and returns the key-value mapping: def mapping(section): return section.mapping Even with the above, I'm still not 100% sure what specifying keytypes does for me, or why or when I'd want to use it. On the face of the above, if it makes it easier to use generalize base section types, then it might be a good idea. The specific base section type I wanted to provide as part of a standard library of section type was just such a mapping section as described above. If both of the proposals are considered acceptable, I'd be able to provide a basic type that could be specialized to use email addresses as keys very simply: import package=ZConfig.components.basic / sectiontype name=email-mapping keytype=mypkg.datatypes.email_address extends=ZConfig.components.basic.mapping / No need to monkey around with the weird key name=+ .../ stuff. ;-) -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] ZConfig: a wish list
[EMAIL PROTECTED] writes: Since the wiki Fred created on zope.org doesn't (or didn't) seem to work, I'll post my wish list here. Good strategy. ;-) The wiki definately didn't work, and no one seems to know why. Feel free to tell me why I don't really want what I think I want. :) Rest assured, my life is based on telling you why you don't really want *that*! - import honors prefixy In my schemas, I have a number of import statements, each with package and file attributes (since the default component.xml naming scheme doesn't work for my code layout). Unfortunately, if my schema tag has a prefix attribute, import's package attribute doesn't honor it, so there's a lot of duplication. For example: schema prefix=mailman.config.components import file=databases.xml import file=domains.xml ... +0 Well, import package=.foo/ doesn't honor the prefix, but that's not the same as what you describe above really (you're using the prefix instead of an omitted package). I agree that the package attribute should use the prefix; will fix. Regarding an omitted package attribute being replaced by the prefix, I think that's fine as long as there's a file attribute. No existing schema is affected. - $ substitutions in defaults Often, my defaults for keys can be expressed in terms of $ substitutions that are more general for my system. Unfortunately, there doesn't seem to be any way to make this work. ZConfig itself doesn't perform $ substitutions on default values, and there doesn't appear to be a way to get at %define variables from Python. -1 This would mean that a schema could require that certain %define names be provided by a configuration. It's certainly possible to make changes to ZConfig to support this, but they'd be fairly substantial. The current model makes the %define and $-substitution a syntactic detail of the configuration language. One of the chief motivations for this is to allow some directory to be specified as the home for other directories to be specified relative to. For example, log files might be specified relative to a log directory or an instance home directory. My usual response has been that it can already be done reasonably using something like: %define topdir /some/path/to/the/top/of/my/tree %define logdir $topdir/log some-logfile $logdir/interesting.log other-logfile $logdir/another.log Another possibility is to perform os.path.join() operations using the base and relative portions in the application. This is less than ideal, but quite workable. Still another possibility is that a new relative-directory type be implemented and some way to say relative-to-what (where what is some other setting, possibly at an outer layer in the configuration hierarchy). References to outer layers of the hierarchy makes this tedious to implement at best. Given that it's not clear that this is needed, the additional complexity seems excessive. If you have a (real) use case not related to specifying absolute directories, or for which the $-substitution approach isn't viable, please tell us about it. - default sections At some point I thought it might be nice to be able to define default sections, so that you wouldn't have to require something like defaultsect/ in your config file. +1 This is something Chris and I wanted from the beginning, but we never decided on the best way to approach it. - Python command substitutions Something like: %define hostname socket.getfqdn() although I know there are some difficult issues with this (imports for one). Do you really want this, or would some way to pre-define %define names be sufficient? This feels slightly less nasty than requiring %define from the schema. It would require opening up the API a little more, though. - attributes default to type When defining a section, if I don't provide a section name, it would be nice if the attribute was defaulted to the section type. E.g. in this example: section type=databases name=* required=yes attribute=databases/ IWBNI I didn't have to duplicate the databases string. -0 This seems like a really minor bit of syntactic sugar. It would be easy to implement, but doesn't seem like it really buys much. I'd be more interested in making name optional, defaulting to *, if attribute is specified. That's about the same amount of sugar, and seems more useful 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 )
[Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension
Phillip J. Eby writes: Well, in that case, can we have a 'getItems()' that returns only the key-value pairs for actual attributes, and does *not* include keys for values that weren't explicitly specified in the configuration file and don't have defaults? Not a bad idea. It will require snaking information through ZConfig.matcher a bit differently, but shouldn't be particularly difficult. Unless of course the keys were strings rather than Unicode, in which case it'd be even simpler. Yes, and so they should be (strings rather than Unicode, that is). I've changed this in CVS. It was never intended that identifiers be Unicode; this was simply an accident of implementation. (The issue here is that Python requires keyword arguments to be strings rather than Unicode, even though attribute names can be Unicode. ZConfig sets attributes using unicode because ZConfig schemas are XML, and therefore Unicode.) Annoying, isn't it? Not sure it's worth fixing in Python. -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: Section type datatype inheritance
This past September, Phillip Eby and I discussed a variety of ZConfig issues on one list or another. Two particular issues I've thought more about, and think I'm reversing myself on them. ;-) I'm going to describe each issue in a separate email, including why I've changed my mind about them and what the consequences are for ZConfig users. Please respond to these messages if you think the proposed changes will have a negative impact on working code. Inheritance of the datatype when extending a section type --- Currently, ZConfig section types that extend another do not inherit the datatype of the type they extend. Phillip argued that, at least for schema extensions, the datatype should be inherited from the base schema. I thought it better to explicity request the same datatype was a better approach because of way we've been using ZConfig in some of the core packages. Each concrete section type really uses a different datatype; sharing configuration handling is accomplished only within Python. When this is the only way section types are being used, explicit is the only way to do things. While trying to create some fairly basic section types that are easy to specialize using extension, this can be less than desirable. What it boils down to is that it's difficult to create section types that can be easily specialized with a minimum of additional information in the schema; a fair bit of boilerplate is needed to change a small amount of behavior. If we add inheritance of the datatype for section types, this affects only section types that extend another section type where the base specifies a datatype and the derived type does not; in that case, the datatype of the base will be used instead of the null datatype. If the null datatype is needed, section types that expect it to be used can add the attribute datatype=null to achieve the current effect (in fact, that works now). No existing unit tests are affected. -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: Keytype and section type extension
This is the second of two messages proposing ZConfig changes. keytype override and section type extension - ZConfig currently requires that derived section types not specify a keytype attribute, used to change the interpretation of the keys. The intent is to ensure that keys defined in the base section type will still be recognized and associated with the same (or equivalent) settings for the derived type. In most cases, this is reasonable behavior. Unfortunately, it makes it tedious to specialize general base section types in some cases. Of particular interest is the case of section types that define no specific keys, but accept arbitrary keys using key name=+ attribute=some_mapping/ For such cases, it can be desirable to change what keys are inserted into the mapping by changing the keytype of the encosing section type. Allowing keytype overrides would not affect any existing schema, since such schema are currently rejected. One unit test would need to change; the test currently checks that specifying a keytype for a derived section type raises a SchemaError exception. -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] apply()'s PendingDeprecationWarning
Python 2.3, 2.3.1, and 2.3.2 generate a PendingDeprecationWarning when apply() is called. This is reasonable since apply() has been deprecated, but can be a real nuissance for code that intends to be portable to Python versions back to 1.5.2. Unfortunately, the logging package distributed with Python has that constraint (don't ask why, please; I really don't know!). Anyone watching the results of the test runs has probably noticed that these warnings are polluting the test output still, and aren't being triggered by Zope code. Guido has conceded that these warnings can be removed from Python, so I've removed them for the upcoming Python 2.3.3 release as well as for the future Python 2.4. Just thought everyone would be thrilled to know. ;-) -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] typo fix
J. Cameron Cooper writes: Here's a super-quick bug fix for someone with a Zope development tree. I'm currently trying to decide how one might turn a directive. Zope/skel/etc/zope.conf # If this directive is turned, Zope performs 'product installation' # If this directive is turned on, Zope performs 'product installation' Thanks! I've fixed this for 2.7 and the development trunk. -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] Rendering xml content in ZPT
Florent Guillaume writes: That's a packaging bug in the packaged Linux binary versions of Zope 2.6.* that Zope Corp won't fix, cf the bug tracker (and anyway there will be no binary versions for Zope 2.7.*). The package is missing some shared library files for expat. You'll have to use your own installation of python. Another solution would be to use the bundled Python to install a recent version of PyXML; Expat is bundled directly and does not require any external libraries. This is also the approach taken in newer versions of Python (2.3 and newer). -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] Rendering xml content in ZPT
Antonio Beamud Montero writes: I have downloaded the last version of PyXML and I have installed using the python version of Zope 2.6 and all was sucessfully, but doesn't work either... Interesting. There should be a reasonable work-around for this; if you could check the existing report in the issue tracker and make sure it's complete (including the complete error message and any traceback information), and assign it to me to look into a work-around, I'd appreciate 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] Zope doesn't know enough mime types.
Chris McDonough writes: Oo, oo, Fred. I just checked in a feature on the HEAD only that lets you configure Python warning filters using the config file. I think it passes Brian's criterion for merge save for any tests. The MIME types support now passes Brian's criteria; I finally added a stanza to the zope.conf.in file that describes it. It would be nice to have all the config stuff the same on HEAD as on 2.7 so we don't run into merge problems later... If we agree and I promise to write a test for the warnfilter, maybe you could just copy the Have you written these tests yet? zconfig schemas and datatype files from the HEAD for the Zope.Startup package and the zLOG package and merge that way instead of surgically porting the mimetypes stuff to the 2.7 branch. The zope.conf.in file needs to be merged as well. What was affected in zLOG? I'm glad to port these features to Zope 2.7 if you've got the tests ready and Brian thinks that makes sense. -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 doesn't know enough mime types.
Chris McDonough writes: Thats where I defined the sectiontype. I don't think it belongs there; it really has nothing to do with the logging. -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 doesn't know enough mime types.
Chris McDonough writes: I was thinking that too after I did it. ;-) I'll move it to Zope.Startup. Cool. I'll be so bold as to suggest using a separate ZConfig component instead of sticking the section definition in the main schema. If you define the section type in warningfilter.xml, import it using import package=Zope.Startup file=warningfilter.xml / in the main schema. Any datatype or handler functions can then be in a separate module within Zope.Startup as well, keeping it nicely compartmentalized. -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 doesn't know enough mime types.
Brian Lloyd writes: fyi, I'm ok with merging this to 2.7 if it already is on the HEAD, has tests, and has at least some minimal docs. It's on the head, and I've performed a check on a running Zope process that new types specified this way are recognized. I'll check in unit tests of the lower-level functionality that supports the feature shortly. The feature is documented in the configuration schema, and I'll add something to the example configuration about it 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 )
Re: [Zope-dev] Zope doesn't know enough mime types.
I wrote: Adding some configuration to Zope to identify additional mime.types files to load may be a good idea, and should not be too difficult. I've done this on the Zope 2 head; I don't know if it should be ported to the Zope 2.7 branch. Zope's configuration file can now have an additional key, mime-types, which specifies an additional file of MIME type associations to filename extensions. The key may be given more than once if desired. The MIME type associations are specified in the same way as in Apache's mime.types file. Each line in the file may be blank, a comment starting with #, or a type association: foo/bar ext foo/bat foo/baz ext1 ext2 ext3 -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 doesn't know enough mime types.
robert writes: would be nice if we had it in 2.7 That's up to Brian Lloyd. I think it's a low-risk change, but we really want to stabilize and finish 2.7. -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] Failure on make instance
Sidnei da Silva writes: I just cvs'upped zope from the 2.7 branch, make clean; make; make instance; and it failed with: running install_data error: can't copy 'zdaemon/component.xml': no matching files make: *** [install] Error 1 Looks like a file is missing, or some script wasn't updated. Sigh. I was looking over this problem this morning when our automated tests screamed foul, and I couldn't reproduce it. ;-( Of course, once your mail arrived, it was a lot easier t fix for some reason(!). When I'd applied the patch from the trunk, I'd applied, tested, and committed; what I didn't do was cvs add the new files on the 2.7 branch! Sorry for the resulting autotest spewage. The files have now been added on the branch, so the testers should be happier. And it should actually work for you. -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] Failure on make instance
Sidnei da Silva writes: Maybe because the phrase 'file missing' triggered something :) Something like that, perhaps! Jeremy's comment wasn't so different, but didn't clue me in the same way. I'm glad to have fixed it for you! -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 doesn't know enough mime types.
Romain Slootmaekers writes: But why the modified mimetypes file has to contain about 40 less mime-types than the corresponding file in a python installation from python.org is a mistery to me. The mimetypes module in general has a problem: the known MIME types are stored in the source code. The table in the module has definately been extended over time; make sure you're looking at the right version of the module from python.org. The module *tries* to load definitions from known external lists of MIME types (as would have been installed with Apache or Netscape), but isn't guaranteed to find these external lists (they not be installed, or may be installed in atypical locations). Adding some configuration to Zope to identify additional mime.types files to load may be a good idea, and should not be too difficult. -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: [Zope] Using 2.3.2 for Zope 2.7
On Fri, 2003-10-03 at 17:27, Jamie Heilman wrote: In 2.3 you can no longer declare new classes in a Script object. It bitches about a lack of __name__ attribute. I haven't really had the time to look into it closely, but it does effect the examples shipped with zope, and actually its just a very useful thing to be able to do. Whatever this problem stems from, there will probably be more because of it. In Python 2.3.x, when a class is defined the __name__ of the encompassing module is looked up. I suspect Python Scripts can be fixed by defining __name__ in the globals dictionary in which the code is executed. -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] Re: [Zope-dev] Using 2.3.2 for Zope 2.7
Paul Winkler writes: then by all means, 2.3.2. These audits seem to be hard to get going on a regular basis (we've been on python 2.1.3 for how long now?) so I see no point in blessing a version of python that's already not latest-and-greatest. It's not just that Python 2.2.3 is no longer the latest and greatest, but that it's no longer on a maintenance track; that's what 2.3.x is. The only counterargument i can think of is that 2.3 may not be bundled with many linux distros yet. I've always compiled my own python for use with zope, so I don't know how big a deal that is. If someone can set up Zope, they can install Python in their sleep. I don't think this is an issue at all. -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: [Zope] Using 2.3.2 for Zope 2.7
Chris McDonough writes: Currently, Zope still claims it works with 2.2.X (via the configure script's acceptable versions feature). Should we continue to make that claim true by not depending on any Python 2.3-specific features in the Zope core? I don't think there are a lot of super-compelling core and/or library differences between Pythons 2.3.2 and 2.2.3 that would make this a hardship on core Zope developers. Requiring 2.3 (any flavor) would allow us to drop the copy of the logging package from Zope 2.7 and newer. There are greater benefits for Zope 3, where we have several modules and packages laying around that would no longer be needed (logging, csv, gettext). I also don't know that we should consider 2.3.1 acceptable for any version of Zope. -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 changes
Phillip Eby and I both checked new functionality into ZConfig today; the documentation has been updated. If these changes are still looking good in a week or two, I'll plan on releasing it as ZConfig 2.0. Both sets of changes revolve around schema extension, but they support different things. Phillip's changes allow one schema to be derived from one or more other schema. My changes allow configuration files to load additional schema components. Please try these changes and see how they work for you. -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] PythonLibraries Product
Tres Seaver writes: Actually, the restricted case is the one which has the real win; the free-floating library is pretty, but not semanticaally needed. An added argument: a ZPT with its own private library becomes, in effect, a Zope3 view component; adopting such beasts will ease migration to Zope3. And it keeps all the pieces easy to locate! +1 For the filesystem representation: what if we just have two files for templates with libraries: 'foo.html' and 'foo.html.py'? Tools will like that better than either of the approaches which try to preserve the twins as a single file: The current Zope 3 filesystem synchronization doesn't currently support writing multiple files for a single object; every object is expected to be either file-like or directory-like. There are a few ways to approach serialization of a view that contains both a template and Python code: - Serialize it as a directory containing two files. - Serialize it as a file containing the template, and make the Python code live as an extra, which would be written to a file in the metadata storage area (tedious to work with, but could be an otherwise normal .py file). - Change the filesystem serialization so that multiple files can be generated to represent a single object. I think this would require a substantial amount of work. -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: tal i18n and ZopeStarter test failures
Chris Withers writes: Can I take a peak at the config.xml you're using for autotester.py? I'm running make ftest test from the command line. What versions of python are you using for Python 2.1 and Python 2.2 resepctively? Python 2.2.3 for everything. -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: tal i18n and ZopeStarter test failures
Chris Withers writes: I see these tests fail on both Windows and Linux. What gives? Who checked in this code without running the tests?! As I've indicated previously, I don't see these tests failing on Linux at all. -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] A First Look at Zope3
Chris Gray writes: I checked out Zope3 from CVS yesterday and had a go at it for the first time. Granted that it is a work in progress, I did have a few comments from a user's (rather than a developer's) perspective. Thanks for taking the time to look at Zope 3! We definately appreciate comments from users and potential users. About the new look to adding objects in a folder -- I see the point of going to a list of contents with a text input to assign a name (so you can see what names are already in use), This can vary based on the type of object and how it's been configured. but I see one problems. The text input appears at the top of the list and the button to commit the change is at the bottom of the list. This will become more inconvenient as a container's list of contents grows. Perhaps the buttons should always be near the text input. That's a good idea, and very reasonable. I will take this opportunity to note that simply pressing Enter (or Return, depending on your keyboard!) will submit the form as well. There is a zope3-dev list available that specifically deals with Zope 3; sending your comments and observations there will reach more of the active Zope 3 developers. -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: TALES idea: tuple unpacking
Shane Hathaway writes: - You have to be careful not to use double quotes in expressions. (Ampersands and less-than/greater-than signs are tricky too. Watch out for pairs of hyphens!) This is FUD. TAL can handle these things quite well; the problem is that many web developers don't have a clear understanding of layers of encoding (a seriously unfortunate state of affairs, though understandable given the time pressures of creating/updating a site). Encoding quotes inside an attribute values means that the expression (Python or not) is harder to read, but if it doesn't still work, there's a bug in the implementation. I'll be glad to donate some of my time to fix any such bugs. Othan than this, I agree with you on this topic. -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: TALES idea: tuple unpacking
Shane Hathaway writes: I'm not quite sure what you're saying. The following fails compilation: span tal:content=python: abc / That's because you've broken the syntax. It should have been: span tal:content=python: quot;abcquot; / or, more legibly, span tal:content=python: 'abc' / I think the problem is that it's easy to think of TAL as little bits of different syntaxes, but that's not actually what's happening. The syntaxes are layered on top of each other, and where there are characters meaningful to more than one layer, they have to be encoded so they are interpreted by the proper layer. Hence you need to be careful not to use double quotes in expressions. I run into this every day. I'm a little wary of expressions like this: span tal:content=python: 1 0 / ... being converted by buggy XML or HTML software to this (I've seen it happen before): span tal:content=python: 1 gt; 0 / That's not buggy; that's what you should have written to start with. Finally, if you use a pair of hyphens in an expression and later use XML syntax to comment it out while leaving the pair of hyphens, the block is technically not well-formed. http://www.w3.org/TR/REC-xml#sec-comments For example: !-- span tal:content=python: 'What should we do--walk or run?' / -- This is not something that should bother anyone, but I wanted to support my assertion. ;-) That's life. If you change the document, you may have to change context. If you want to make it possible to enclose something in a comment, you have to encode your content differently. For the double hyphen, encode at least one of them like so: !-- span tal:content=python: 'What should we do#45;-walk or run?' / -- In general, I'd recommend using a syntax-highlighting editor to help detect this one early, or even a proper XML editor for those who can tolerate them. I hope this makes sense as I've described 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] breaking apart INSTANCE_HOME.
Chris McDonough writes: I propose that we add two more options to the config file: import-directory extensions-directory I'd like to suggest that we call these imports and extensions, to be parallel with the products multikey. For products, we use the specified directories to add to the Products package, but that makes sense given that the base Products package is a required component. For imports and extensions, we should consider using the specified directories *instead* of the default. This is easy enough; if the directories are given as relative directories, they should be resolved relative to config.instancehome; the schema can then include the defaults and very little new code will be needed. I'm sure that utilizing these options in the config file will break things that rely on having a monolithic INSTANCE_HOME such as products that attempt to do something like import_dir = os.path.join(INSTANCE_HOME, 'import'). Any product that does that will prove fragile eventually. We just need to make sure the core doesn't do anything like that. ;-) So I propose that the stock Zope instance home install continue to follow the old pattern (where everything is installed into a single instance home directory), but we provide the advanced config file options for roll-your-own packagers and advanced users. This sounds like a really good plan 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: [Zope-dev] breaking apart INSTANCE_HOME.
Chris McDonough writes: Actually, both of these directories have historically worked in much the same way as the Products package does. Ok, well, that's still not hard to do; we just add the bootstrap directories to each of the lists once we've read the config. A software home may have (actually currently must have) an import directory. Zope currently slurps various TTW examples from a zexp file in the software home import directory. I'd really like to dump this dependency, but it would take a bit of work. Ah, that's right. I keep trying to forget about that. One approach may be to use the import mechanism but not the import search mechanism for that. So there's still a .zexp file in the software, but it's not part of the general import/export support. The Extensions directory... errr.. this should probably not be in a software home anymore. I can't think of anything that would break were it to not be there anymore (besides products that depend on the physical layout of the software home, which shouldn't exist). So this one doesn't present a problem. The default list will only include the Extensions in the INSTANCE_HOME, and configuration will override that if something else is desired. Personally, I think we should just hardcode '/home/fred/zope/import' into the core as the import directory and be done with it. ;-) That's fine with me. At least it won't be accessing *your* imports directory. ;-) -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] TALES idea: tuple unpacking
Paul Winkler writes:
In this case, consider a trivial change to (or wrapper around)
listFilesByUser to make it return a sequence of dictionaries
like {'user': some_user, 'files': (file1, file2...)}
This is exactly what the proposal I posted a couple of weeks ago was
trying to avoid. While adding another layer of indirection around the
actual call to listFilesByUser() isn't all that costly, these things
add up, especially since so many temporary objects are getting created
and thrown away.
I know for Zope 3, we'd like to get away from having to write a view
class simply to hook up helpers like this when something simpler would
do.
So far, two distinct approaches have been presented, with minor
variations for each. I won't go into the variations, but the two
approaches are:
- Use a Python-like sequence unpacking syntax. This is probably most
comfortable to template authors who are Python programmers first,
and web guys (or gals!) second.
- Use the namespace qualifiers to get an adapter to handle converting
container lookup to a sequence indexing operation. This plays off
the machinery being built anyway, so is quite attractive, and
doesn't affect the basic syntax or implementation of TAL, but only
of the TALES expression engine. This is very attractive because it
pushes the support for this feature somewhere the application
controls in as much detail as it wants.
-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] TALES idea: tuple unpacking
Gilles Lenfant writes: I'm interrested into adding some other wishes for the next ZPT versions. Where could those wishes be posted ? This is the place. There's only very limited resources available at Zope Corp to make changes happen right now, so be prepared to help make changes if there's concensus that your proposal should be accepted. -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: TALES idea: tuple unpacking
Philipp von Weitershausen writes: Why wouldn't that be possible with a_list/index:?i? I think making it a_list/index:i is fine. The adapter for index: will get the index as a string and convert that to an integer and return a_list[i]. The index: adapter simply represents a namespace in which all names look like integers. -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: TALES idea: tuple unpacking
Paul Winkler writes: I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python? I really think that's a mistake. There are those that consider using python: expressions in ZPT should be discouraged, primarily because it's yet another syntax for a web developer to learn. I'm not necessarily one of them, but I am sympathetic with that reasoning. -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] current zope2 head warnings with cur-cvs python
Anthony Baxter writes: Running the current Zope2 HEAD with current-cvs python, starting gives the following 3 warnings. /home/anthony/src/zope/ZopeHead/lib/python/ZServer/medusa/test/max_sockets.py:53: DeprecationWarning: integer argument expected, got float for i in range(1 + len(sl) * 0.05): /home/anthony/src/zope/ZopeHead/lib/python/AccessControl/User.py:438: DeprecationWarning: assignment shadows builtin SpecialUsers.super=emergency_user These two are now fixed. -- 2003-07-11T22:40:10 PROBLEM(100) OFS.Application Duplicate Product name After loading Product 'README.txt' from '/tmp/z27/Products', I skipped the one in '/home/anthony/src/zope/ZopeHead/Products'. Hmm. -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] setup.py bug
Eugene Morozov writes: I've decided to try Zope 2.7 from CVS. I prefer to package everything installed on my system, so I've built Zope RPM package but it didn't work with ZEO because setup.py doesn't install ZEO.auth package. You're right; I've added this to the current Zope 2.7 CVS. -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] ./configure on Zope27HEAD with Python 2.2.2
Jamie Heilman writes: Does anyone care enough to fix configure to work properly on BSD? i=$(($i+1)) Whatever happened to the old tried-but-true: i=`expr $i + 1` Running an external process may be slower, but you don't need to run ./configure all that often unless you're developing Zope itself (and even then, not all *that* often). I suspect using expr is more portable to the whole family of sh-derived shells than any of the more new-fangled ways. Sheesh, who ever imagined I'd be the curmudgeon? -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 1.0 release
I've just released ZConfig 1.0 for people who'd like to try it out outside of Zope. Chris McDonough will be presenting our paper on ZConfig at PyCon DC on Thursday; be sure to catch it! ZConfig is a configuration library intended for general use. It supports a hierarchical schema-driven configuration model that allows a schema to specify data conversion routines written in Python. ZConfig's model is very different from the model support by the ConfigParser module found in Python's standard library, and is more suitable to configuration-intensive applications. ZConfig schema are written in an XML-based language and are able to import schema components provided by Python packages. Since components are able to bind to conversion functions provided by Python code in the package (or elsewhere), configuration objects can be arbitrarily complex, with values that have been verified against arbitrary constraints. This makes it easy for applications to separate configuration support from configuration loading even with configuration data being defined and consumed by a wide range of separate packages. ZConfig is licensed under the Zope Public License, version 2.0. See the file LICENSE.txt in the distribution for the full license text. Information on the latest released version of the ZConfig package is available at http://www.zope.org/Members/fdrake/zconfig/ Reference documentation is available in the ZConfig/doc/ directory of the distribution. -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] ch-ch-ch-changes (post-merge fallout)
Jamie Heilman writes: I'm slowly fumbling my way through the massive changes of the latest branch merge... am I missing where the open databases (Globals.opened) get closed, or did that just get dropped entirely (and if so, how does that relate to the goals of the clean shutdown work)? Hmm. I hope that didn't get lost! I'll look into this to be sure. Also, now that the hacked asyncore is no longer wedged into place in ZServer/__init__.py are there any known gotchas if one should import say, Zope and running Zope.startup() before importing ZServer? Not that I plan on doing that mind you, but the side-effects that Zope 2 suffers from in its various import dependancies drive me up a wall. It'd be cool if that one got fixed. There's no longer a hacked version of asyncore, so that particular constraint should no longer hold. I agree that import order dependencies are a significant source of obfuscation. -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] New installer branch
Christian Theune writes: I'm reconfiguring my dev setup for the freshly merged new installer. My zope instances refuse to load the products from the Products directory but don't complain. Here my configured Pathes: I think I see the problem; will see what I can do about this one. Thanks! -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] New installer branch
Christian Theune writes: I'm reconfiguring my dev setup for the freshly merged new installer. My zope instances refuse to load the products from the Products directory but don't complain. Here my configured Pathes: Fred L. Drake, Jr. writes: I think I see the problem; will see what I can do about this one. I've committed a fix for this, but it does differ slightly from the Zope 2.6 approach. I think the new way matches the rest of the new configuration philosophy much more effectively. Instead of simply checking for INSTANCE_HOME/Products, the directories used to define the Products package are listed in the configuration file (the standard Products are included regardless). The INSTANCE_HOME/Products directory is included in the default configuration file; it can actually be removed if desired. The configuration file can completely control the order in which the directories are searched. Please let me know if you have any difficulties with this approach. -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] Merging the new-install-branch
Chris Withers writes: Will I have to change the way Zope is built and/or the etsts are run? Yes. If so, where could I find otu what they now need to look like? There is a scenario for Linux in the newinstallbranch.xml in Packages/TestScripts; I'll test it again before the merge takes place. I don't know about the Windows scenario, but it's probably OK for now. It may need to change in the future (I'll try to help as much as possible; Tim just tried the new-install-branch tests on Windows and we found one buglet there). I won't be in front of a Windows box myself until tonight. -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] Merging the new-install-branch
I wrote: I'll send a note to the zope-coders list before I actually start the merge. For a description of the changes (and the ensuing discussion), refer to this thread: http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html The unit tests work on Windows for the branch at this point, so I don't expect any real surprises there just yet. I'm starting the mechanics of the merge into the trunk now; I'll send another email when the merge is complete. Anyone running an automated test of the Zope 2 trunk should review this message to determine what impact this will have on the test process: http://mail.zope.org/pipermail/zope-coders/2003-March/003450.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 )
Re: [Zope-dev] Re: [Zope-Coders] Merging the new-install-branch
Fred L. Drake, Jr. writes: I'm starting the mechanics of the merge into the trunk now; I'll send another email when the merge is complete. I'm done. The new-install-branch is now dead. -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] Proposed installation changes for review
Adrian van den Dries writes: The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else. The build and install targets just call setup.py, so is this a bug in the distutils? This still essentially does an in place build, which is what the previous Makefile did as well. Offhand, I'm not sure how difficult it would be to support both in-place and out-of-place builds; I may be able to look into it tomorrow. How important is it to support out-of-place builds? -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] Proposed installation changes for review
Adrian van den Dries writes: On March 19, Fred L. Drake, Jr. wrote: How important is it to support out-of-place builds? http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration Ok, I'm too tired to read that now; I'll look at it tomorrow between meetings. configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter. INSTANCE_HOME setup becomes the default kind of installation. Is this still current? Can't say about the wiki offhand, but the quoted statement still applies. doc/INSTALL.txt has been updated; see the section Building Zope for the relevant procedure. (The Quick Start section uses an abbreviated procedure that creates an instance home in the source directory.) Time for me to get some sleep. ;-) -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] Proposed installation changes for review
Adrian van den Dries writes: Debug mode needs to be broken out into directives for its real effects. I always want Zope to run as a daemon, but I also want automatic PT/DTML reloading, and immediate tracebacks. I think there should be a separate no-detach for those people who want that feature. I'm happy with this (more so than the single option). I think it's fair for us to get this implemented before we're done; not sure if it has to happen before the merge (I'm mostly tied up this week). The ZODB section doesn't work: Error: 'mount-point' is not a known key name I think we haven't spend enough time figuring out the right way to deal with DBTab-style mounts yet; leave out that key for now. To see the current spellings of the storage- and database-related configuration values, take a look at the ZConfig schema component in the ZODB package: lib/python/ZODB/component.xml Also, it needs to support arbitrary storage types. I don't know how ZConfig works internally, but I'm guessing each storage type would supply a ZConfig thingie that registers its configuration paramaters to ZConfig. I'm hoping to roll out some large production Zopes with partitioned, distributed storages. I'm not sure what you mean; it sounds like you're looking for either DBTab-style mounts or something different. Please describe the configuration so we can be sure that there's some way to support it. Thanks for your comments! -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] Re: [Zope-dev] Proposed installation changes for review
Edward Muller writes: Actually I like the way z2.py detaches or doesn't detach. Perhaps a separate config option would be good to control this. Detaching, or daemonizing, will be a separate configuration parameter from everything else. The basic mechanism will be that provided by the zdctl.py/zdrun.py scripts in the zdaemon package. -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: [Zope-CMF] i18n for CMF And Plone,backporting i18n to Zope 2.x
Barry A. Warsaw writes: concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML. Well, faster than it used to. We need to spend time on performance. So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will perform adequately? It might be time to investigate Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ -Fred -- Fred L. Drake, Jr. fdrake at acm.org PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?
Jens Vagelpohl writes: mac OS X browsers: - IE 5.1 - mozilla 0.99 (=1.0) i won't include OmniWeb because its CSS support is still flaky. Whether a browser should be included depends on what portion of the audience uses it, not how broken it may be. I don't see it listed in the stats you sent earlier, but I don't know if it spoofs itself to get reasonable behavior from sites that require you to run the same browser as the site designer. (I know Opera spoofed itself as MSIE by default at one point; since Opera 6 was in your stats, I presume that version doesn't do that.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?
Stephan Richter writes: I think we can safely rely on CSS. Common, Zope 3 is a new product, and if someone needs to make it backward Browser-compatible, he can always implement a less fancy CSS-free skin. Argh! I can hear Guido tell us about his Netscape 4 now... There are still a *lot* of people using that one and it's ilk. Browsers at that level know just enough CSS to make it painful. ;-( I've spent more time making the Python docs work in NS4 than making them look good in more modern browsers, and the more advanced efforts I've made can't go in because the older browsers just don't come close! -Fred -- Fred L. Drake, Jr. fdrake at acm.org PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Are there Graphic Designers?
William Trenker writes: Would you be comfortable with CSS Level 2? My own thought is that we could use CSS 2 and as much of CSS 3 as we can coax out of advanced browsers. We should use the advanced CSS features to avoid needing *Script, since that's evil and many users turn it off due to security and privacy concerns. -Fred -- Fred L. Drake, Jr. fdrake at acm.org PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
