[Zope-dev] Re: [ZODB-Dev] Re: End-of-line translation problem
On Fri, 2004-04-30 at 10:48, Philipp von Weitershausen wrote: But, as the -kb property in CVS has shown, newbies tend to forget these things. Then again, setting svn:eol-style after a file has been added to svn is easier than getting -kb on a file that's already in CVS. I often have to cvs admin -kb *.gif *.jpg *.png after the fact. That doesn't seem too difficult, although it would be really nice to have a standard mapping of extensions to file properties. For myself, I'm inclined to do what Tim suggested, and tell subversion to automatically set the eol-style for all files to native. This will fail loudly when binary files are checked in and I think that I can deal with that inconvenience. That does not make sense. You'd only want svn to set that property on text files anyway. So I don't understand what this inconvenience is. Note that this is a big improvement over CVS as generally, binary files will automatically *not* be treated as text files. (The danger being that the binary detection algorithm will occasionally fail.) I think that's very rare. It has never happened to me at least, and I have lots of binary stuff like OpenOffice files in my repository. [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg I wouldn't mind such a configuration. I would really make it the responsbility of the committer. He/she may choose to use such settings or simply set svn:eol-style after every 'svn add' manually. +1. I wish the subversion folks would support file extension to attribute mappings. -Barry ___ 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: [ZODB-Dev] Re: End-of-line translation problem
On Fri, 2004-04-30 at 11:33, Jim Fulton wrote: Jim Fulton wrote: ... http://subversion.tigris.org/servlets/BrowseList?list=usersby=threadfrom=184061 Ken pointed out that the links on this page don't work. :( Sigh Neither do many of the next in thread and previous in thread links. pipermail-doesn't-look-so-bad-now-ly y'rs, -Barry ___ 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 Mon, 2004-04-26 at 15:23, Jim Fulton wrote: 2. Convert the mainline history, but leave off the branches. Would this mean we'd lose the log messages too? If so -1 because often merge messages aren't very helpful. merged foo-bar-branch to head would suck if you couldn't at least see the log messages on that branch. Otherwise, -0. Disk is cheap but history priceless. -Barry ___ 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 Mon, 2004-04-26 at 15:42, Jim Fulton wrote: The reason that I hate merge messages like this is that I find it very difficult to find the branch checkin messages in thye log. It's possible, but so difficult that I generally would rather not bother. I agree, but history is history, so we have to live with what we've got in there. Is your only objection the disk space it consumes? -Barry ___ 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: [ZODB-Dev] Subversion repository layout
On Mon, 2004-04-26 at 15:48, Tim Peters wrote: [Jim] I read some subversion docs over the weekend, and so am sufficiently prepared to live with the oddities of a standard subversion layout. I think that if you make a non-standard layout, then everyone coming to, or going from, Zope from/to other subversion projects will be forever tripping over the uniqueness of Zope's setup. IOW, the existing subversion docs cover the standard layout quite well. If we do something unique, I'm afraid it becomes another piece of folklore that will be impossible to guess and difficult to find out about. The other thing is that -- for me w/cvs at least -- full checkouts are rare. Usually I do a single checkout and then tons of updates, which never require the paths to be given. -Barry ___ 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] Re: [Zope-dev] zLOG is dead
On Tue, 2004-04-20 at 10:01, Chris Withers wrote: This discussion smells like that string should be computed from introspection. Why can't it be computed from introspecting whatever code called the log method? You probably could do it via sys._getframe(). I'm not sure you should though. ;) (btw, is there an intro to Python's logger stuff? looks like I need to get up to speed on this...) AFAIK, the online logging package docs are about it. That's not the easiest way to learn how to use the package unfortunately. -Barry ___ 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: Proposal: Rename zope package
On Tue, 2004-04-20 at 15:46, Fred Drake wrote: On Tuesday 20 April 2004 12:08 pm, Jim Fulton wrote: What do people think about alternative 4? +1 Okay, add me to the chorus: +1 -Barry ___ 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] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote: From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. I've also heard that zope.schema is going away and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. -Barry ___ 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] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote: Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal. That's very comforting! I like that it forces developers to be deliberate when adding cross-subpackage dependencies. -Barry ___ 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] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote: Additionally (and Jim and I have discussed this amongst ourselves) I feel strongly that the dependancies should be enforced by tests. Good point. The dependancy tests might need to be separate from unittests because they would probably require an import hook or somesuch. Perhaps a tool like pychecker could be leveraged or extended to provide this service. At a minimum this test would need to be run before packaging a distribution, but ideally would happen more often. I wonder if some kind of doctest could be added to the __init__.py of the package that hooked __import__ and then attempted to import each module in the package, tracking the imports. Then complain about anything not defined in DEPENDENCIES.cfg (and hmm, what to do about standard library imports?). Yeah, maybe some kind of pychecker hook would be better. :/ -Barry ___ 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
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote: Because in general I don't like version numbers in the path. I also think that zope is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications. I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :) onions-are-tasty-but-not-in-the-varnish-ly y'rs, -Barry ___ 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
On Tue, 2003-12-30 at 13:48, Fred L. Drake, Jr. wrote: 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? Not yet, because there aren't any wink. 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 hoping there won't. I'd like the ZConfig stuff to define only site-wide configuration stuff, like the ipaddress/port of your smtp servers, the http port and interface for the web server, etc. ZConfig might be used for list config defaults, but I'm not yet sure about that. -Barry ___ 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: Section type datatype inheritance
On Mon, 2003-12-29 at 00:12, Fred L. Drake, Jr. wrote: 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. Cool. I'll comment, and then post a separate message about some things I'd like to see in ZConfig. (Fred created a wiki on zope.org but wikis were broken there and I don't know if they've been fixed.) FTR, of course I'm using ZConfig in various Zope projects that I work on, but I'm also going to be using ZConfig in Mailman 3. 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. This is how I'm using extended section types in my code currently. The proposed change won't affect me because I explicitly specify the data types in derived section types. It seems to me unlikely that you'd have a base section type with a non-default data type, with derived section types that rely on the default data type. +0 -Barry ___ 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
On Mon, 2003-12-29 at 00:28, Fred L. Drake, Jr. wrote: 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. 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. 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. -Barry ___ 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
On Mon, 2003-12-29 at 12:52, Fred L. Drake, Jr. wrote: 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: Ah, that does sound useful! What I think the documentation needs is a kind of overview-slash-motivation-slash-real-life-examples. I'd start with an example configuration file, explain why it was designed that way, then work backwards to the schema and any components being used. That's how I tend to work anyway -- I think about what it is I want my end-users to be able to configure, i.e. I design the user interface for the .conf file first, then I figure out what the schema and component schemas I need to support that. -Barry ___ 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
On Mon, 2003-12-29 at 15:07, Fred L. Drake, Jr. wrote: - $ 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. I suppose that model precludes even access to %define variables after parsing. 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 Which is essentially what I do now. 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. 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. 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. Pre-defining %define names might be sufficient. - 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'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. 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. anything-to-cut-down-on-the-boilerplate-ly y'rs, -Barry ___ 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 )
