Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Paul Winkler <[EMAIL PROTECTED]> wrote: > Only that I have the same question Martijn does: > Can I then override one of those resources and keep the other 34? Perhaps the resourceDirectory directive should just be sugar for a set of resource directives, one for each file in the directory? That would allow individual overrides, and maintain the convenience. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Jeff Shell <[EMAIL PROTECTED]> wrote: > I would prefer not. We've used resourceDirectory to support things > like webcams. The image(s) uploaded by the cams might not always be > there, but the containing path is. It's nice not having Zope start Good point. > If it was sugar for a set of resource directives, this could easily > fail out on us, unless it was making 'resource' items all the time > whenever the directory's contents changed. Right. In which case, another possibility would be to have a new directive that really is just sugar as I described. That would avoid backward compatibility problems and make the intention clear. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/16/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Either way, resource definitions are not quite the goal of my proposal > so I'll leave it out of there. Perhaps Paul or whoever has the need for > it would like to implement a "resourcesFromDirectory" directive... Right; this should definately be a separate proposal. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] merge zope-dev and zope3-dev?
On 2/16/06, Chris Withers <[EMAIL PROTECTED]> wrote: > To be clear: I'm talking _only_ about merging the dev lists, _not_ the > user lists. The users lists are still largely independent, but it seems > like just about every post to the dev list now has a bearing on both > Zope 2 and Zope 3, especially as they become closer and closers... -1 -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
On 3/6/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > In modern Zope[2] schemas, there is a general purpose abstract type > precisely for this kind of extensions. When Tres and I added this, we planned specifically to see how it was received by the Zope 2 community. If people liked the way this was done, it could be added to Zope 3. That said, I don't think Jim's concerns are limited to the Zope configuration schema, but extend to configurations that do not necessarily involve the Zope application server at all. It may be that a better foundation schema is something to experiment with, especially for non-Zope applications. I don't expect to have any time for this in the near future. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: keeping attributes abstract
On 3/9/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
> The disadvantage here, of course, is that the {g,s}etBar methods hang around
> in the class for no reason. Benji's example avoided this.
That's only a disadvantage if you don't want to allow a subclass to
use them; that can be useful at times.
-Fred
--
Fred L. Drake, Jr.
"There is no wealth but life." --John Ruskin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/17/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > As far as I understood, vocabularies are on the way out in Zope 3.3: > > in zope.schema.interfaces: > > # BBB vocabularies are pending deprecation, hopefully in 3.3 That's correct. Gary and I invented vocabularies to solve some problems. Jim followed up with "sources", which have fewer warts. In Zope 3.2, Benji and I added iterable and named sources, so I think sources now have the same basic range of functionality as vocabularies. It should now be possible to use a source wherever a vocabulary was used in the past. > I may have this wrong, but that's what I read in the code. We've used > vocabularies before, but apparently they're deprecated. Please try to revise your applications to use sources. If there's anything missing for sources, it may make sense to delay the deprecation of vocabularies. It would also indicate that what needs to be added to allow sources to replace vocabularies. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/17/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > You're missing the point -- the vocabulary is *not* software, and Python > is *completely* the wrong place to define it: it is *pure* policy. THe > fact that you are administering all the sites you build blinds you to > this fact. Sometimes they are, and sometimes they're not, depending on the specific vocabulary. For the simple case of a drop-down to select from a set of known values, they certainly are policy in many cases. > My examples move the definition of the vocabulary out into integrator / > administratof land, which is where they belong. For vocabularies (or sources) where the set of values really is policy, there are a couple of approaches. One is the CSV-based vocabularies I implemented, which Gary has mentioned recently. This makes the specifc set of terms something that the site admin can update in the database, which works well on sites which need to support live updates within the transactional world. It's also nice when using multiple application servers and ZEO. Another would be a vocabulary stored in a file that isn't updated once the application is in production. I'd rather see a slightly different arrangement for this situation, where the application names vocabularies that are then configured elsewhere. For example, it should be possible to provide a vocabulary by associating the vocabulary name with a CSV file in zope.conf. The details of a vocabulary's semantics would have to be considered of course, even for these highly static vocabularies. Is the title of the term translatable? What translation domain should be used? There are a lot of ideas that still need to be explored in this space. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: zope.org checkin mailing list Re: [Zope3-dev] a plan for widgets?
On 3/17/06, Chris Withers <[EMAIL PROTECTED]> wrote: > I thought that was for one of the many defunct projects to rebuild zope.org? I think that's right. The right list should be Zope-CVS, which seems to be getting email for the separate zope.* projects, but not the zc.* projects. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] eggs for Zope 3 extensions
On 4/4/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Another question about eggs: I assume that Zope 3 extensions at present > cannot be zipped, as Zope needs access to their zcml files. Correct? Extensions that contain ZCML or other file-based resources (page templates, ZConfig schema components) cannot currently be used directly from a ZIP file. I started work to support that on the zipimport-branch, but didn't have time to finish the proposal that went with that. That branch allowed ZCML and page templates to be loaded from within ZIP files, and support code to allow packages to refer to their own resources abstractly, even without the egg-support code being available. The changes on that branch work with ZIP-based imports generally, and are not specific to eggs (but I think they work fine with eggs). There's a wiki page about this at http://dev.zope.org/Zope3/ZIPImportSupportForZope3 -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZOPE3 Maildir implementation
On 4/7/06, Pjotr Prins <[EMAIL PROTECTED]> wrote: > If no one else does it and I feel confident enough... Maybe in a few > months. I've implemented maildir processors before. For ZC, no less. I don't know what happened to the repository that code was in, but it had all the current maildir name selection stuff going on. I'd be happy to take a look at it before too long if the issue lands in the collector. -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.i18n.translate ignores keyword arguments: desired/expected?
On 4/10/06, Gary Poster <[EMAIL PROTECTED]> wrote: > My strawman is that all non-None `translate` keyword arguments should > win over msgid values. +1 > A valid counter-argument for domain, at least, is that this is really > an attribute of the msgid, and overriding it effectively changes the > msgid into an entirely different token. But I'm tempted to go with > simple logic and just say 'keywords override msgids'. This is the only one that could be argued, and I'd be swayed by a reasonable case. Since no one was forthcoming with a rationale, I'd be tempted to make the change so the screams can be heard if there's code that depends on the current behavior. This kind of thing is what alphas and betas are intended to rout. -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] 64-bit BTrees
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I welcome comments. -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [ZODB-Dev] Re: [Zope-dev] Re: 64-bit BTrees
On 4/17/06, Jim Fulton <[EMAIL PROTECTED]> wrote: > The fact that IIBTrees is so widely used is exatly the reason > I want to use 64-bits for the existing types rather than having to > introduce a new type. Oops, I was checking in the separated version of 64-bit BTrees while this was landing in my inbox. ;-/ Once we determine which approach we're going with, I should make an alpha release of ZODB 3.7 and knit that into the Zope 3 trunk so we can get more testing in context. -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 64-bit BTrees
On 4/13/06, Fred Drake <[EMAIL PROTECTED]> wrote: > I've created a feature development branch for > this, and checked in my initial implementation. I've made another branch for this, with a different twist. I'm not sure it'll be interesting, but I think it'll solve my immediate need until I can get around to reasonable testing of the performance implications. The "fdrake-optional-64bits" branch will compile using the C "int" type for "I" keys and values by default, and using the "PY_LONG_LONG" type if ZODB_64BIT_INTS is defined. This allows 64-bit BTrees by building ZODB like this: python setup.py build_ext -D ZODB_64BIT_INTS build BTrees.IIBTree.using64bits will be True if ZODB_64BIT_INTS is used. -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3 trunk and Python 2.5a2
I just tried building the Zope 3 trunk with the Python 2.5 alpha 2 that was released a few hours ago. Unfortunately, the testrunner dies in the standard library. This is probably related to changes in the optparse module; it was updated shortly before the release to the latest Optik release. I don't have time to look into it right now, but if someone does, it would be good to figure out if this is a problem in optparse, or in the way we're using it. Here's the traceback I got: python2.5 setup.py \ build_ext -i install_data --install-dir . running build_ext running build_headers running install_data python2.5 test.py -v Traceback (most recent call last): File "test.py", line 61, in result = testrunner.run(defaults) File "/home/fdrake/projects/Zope/Zope3-py2.5/src/zope/testing/testrunner.py", line 191, in run options = get_options(args, defaults) File "/home/fdrake/projects/Zope/Zope3-py2.5/src/zope/testing/testrunner.py", line 1641, in get_options default_setup, _ = parser.parse_args(default_setup_args) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 1376, in parse_args stop = self._process_args(largs, rargs, values) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 1416, in _process_args self._process_long_opt(rargs, values) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 1491, in _process_long_opt option.process(opt, value, values, self) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 774, in processvalue = self.convert_value(opt, value) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 766, in convert_value return self.check_value(opt, value) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 761, in check_value return checker(self, opt, value) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 420, in check_builtin return cvt(value) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 407, in _parse_int return _parse_num(val, int) File "/home/fdrake/plat/linux/lib/python2.5/optparse.py", line 394, in _parse_num if val[:2].lower() == "0x": # hexadecimal TypeError: unsubscriptable object make: *** [test_inplace] Error 1 -Fred -- Fred L. Drake, Jr. "Don't let schooling interfere with your education." -- Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 lacks Ajax capability?
On 5/15/06, Jeff Rush <[EMAIL PROTECTED]> wrote: I got the definition from Wikipedia: http://en.wikipedia.org/wiki/AJAX "Ajax, shorthand for Asynchronous JavaScript+CSS+DOM+XMLHttpRequest, is a Web development technique for creating interactive web applications." From the page of the guy that coined the name: http://www.adaptivepath.com/publications/essays/archives/000385.php "The name is shorthand for Asynchronous JavaScript + XML". Yes; we agree on this definition of AJAX, I think. :-) The key points re Zope3 are: (1) a piece of Javascript downloaded with a page request turns around and issues an HTTP GET back to Zope3 such that that connection is kept open indefinitely, and the thread within Zope3 that is servicing that request hangs around and periodically shoves bits of data (XML, JSON, whatever) down that This is where we get a disconnect. I've certainly never heard that AJAX specifically requires a server thread to remain dedicated to a particular client. This is fundamentally unscalable, and architecturally fragile at best. The JavaScript in the browser can try to keep an existing connection open using standard HTTP connection controls, certainly, but those never come with a guarantee. Several of us at Zope Corp. have created AJAXian interfaces with Zope on the server side, so I think it's safe to say Zope can do this just fine. The TCP connection itself, however, isn't so precious as you indicate; the ordinary HTTP request/response model is the foundation for AJAX services, and works just fine with Zope. -Fred -- Fred L. Drake, Jr. "Education is hanging around until you've caught on." -- Robert Frost ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 lacks Ajax capability?
On 5/15/06, Jeff Rush <[EMAIL PROTECTED]> wrote: Now that's odd, because to me having 1,000 clients repeatedly poll the server every second, and potentially tearing down/making new TCP connections is less scalable than on a modern OS keeping around 1,000 threads or twisted Well, if you're certain that 1000 clients is enough, that's not so bad. :-) The number of clients and the frequency of requests certainly makes a difference. My comment about fragility remains, of course. Connections can be lost due to external situations. Being able to re-join a session is something that needs to be considered, but it sounds like you're aware of that already. What's right for your application is something you'll need to determine; the details you described in another message certainly do point to wanting some sort of streaming support. In fact, you probably want to stream additions to the chat dialog from other participants and submit messages via AJAX. So you get all the fun of both! ;-) Good luck with your application. -Fred -- Fred L. Drake, Jr. "Education is hanging around until you've caught on." -- Robert Frost ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zc.resourcelibrary/trunk/ A basic makefile, the ZPL and copyright headers.
On 6/15/06, Benji York <[EMAIL PROTECTED]> wrote: There seems to be a consensus (although not an overpowering one) that they be removed. I'll add in my +1 for removal as well, it that helps. :-) -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Disable developer mode by default
On 6/19/06, Christian Theune <[EMAIL PROTECTED]> wrote: Additionally, I might take the time to log a warning when in developer mode, and even more additionally, I'll introduce a red blinking something that tells you in the ZMI that you are running developer mode. +1 to all this! -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: There are bugs that do not need a test once they are fixed. All kinds of "NameError" and "AttributeError" fall into this category. The point of a test in most such cases is that there is a code path that isn't covered by tests, or it would have been caught earlier. A test that exercises the modified bit of code helps assure that future changes to the code don't introduce similar problems by providing at least one pass through the block containing the problem. How pressing the need for the test really is, is a matter for discussion, because the cost of writing the first test for an existing piece of code can be much higher than the cost of the fix. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
On 7/6/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: - Do other people also think it'd be a good idea to come up with some repository guidelines? Stephan had a proposal about specifying package metadata and code maturity/quality, I think it's worth working towards easily accessible info like that. If others agree, then let's get started. Whether Stephan's proposal is exactly the right thing, I don't know (I didn't read it carefully), but something is clearly needed. At the very least, a README.txt at the top-level of each project's trunk seems reasonable (and yes, I know many of the zc.* packages don't have that at the top level). I suspect it's worth reading Stephan's proposal carefully as soon as time allows. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] pkg_resources or pkgutil?
On 5/25/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: I think they do pretty much the same thing (but I could be mistaken). Are they interchangeable? If not, are they compatible so that we just add both ways to both files? If they're not compatible, which one should we use in the future? Looks like no one bothered to answer this. :-( No, they aren't equivalent. The pkg_resources flavor is only effective if pkg_resources is available; I don't think that should be assumed. The pkgutil.extend_path version should be used as the fallback when pkg_resources is not available. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Unused local variable?
On 7/11/06, Chris Withers <[EMAIL PROTECTED]> wrote: Puzzling as to what this chunk of code: if msgid.domain != self.domain: util = getUtility(ITranslationDomain, msgid.domain) I don't see it being used either. I suspect those two lines can be removed. :-) -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope repositories
On 7/13/06, luis <[EMAIL PROTECTED]> wrote: ..or there is also a file package in [Zope] / zope.file / trunk / src / zope / file and another one in [Zope] / Zope3 / trunk / src / zope / app / file These two are different things. There is no relationship between zope.app.file and zope.file. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Remove zwiki-configure and bugtracker-configure?
On 7/18/06, Florian Lindner <[EMAIL PROTECTED]> wrote: since these two packages have been moved out of the trunk is it ok to remove zwiki-configure.zcml and bugtracker-configure.zcml from zopeskel/etc/package-includes? Indeed! -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Remove zwiki-configure and bugtracker-configure?
On 7/18/06, Christian Theune <[EMAIL PROTECTED]> wrote: AFAICT they were removed already, I stumbled over this today as SVN didn't remove them on their own. They get copied into zopeskel/etc/package-includes/ (and thence into instances); those copies don't get remove automatically. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Remove zwiki-configure and bugtracker-configure?
On 7/18/06, Florian Lindner <[EMAIL PROTECTED]> wrote: Ok, I just did a fresh checkout and I see that those files have vanished. Sorry for not checking this first... Not a problem! It's unfortunate those files get stuck in the zopeskel directory. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Trunk Cleanup
On 7/19/06, Benji York <[EMAIL PROTECTED]> wrote: OK. I'd prefer it if they were moved to a subdirectory, but it's not a big deal to me. Same here. I consider them monumentally useless. Moving them elsewhere makes it easier to see what's important in the checkout root. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Subversion Externals
On 7/20/06, Christian Theune <[EMAIL PROTECTED]> wrote: What's the proposed way to handle those things that are externals now? I'm looking forward to Jim's new buildout for these things. Externals are painful, and I'd really rather things like Twisted, ZODB, and ZConfig to be eggs rather than checkouts anyway. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Trunk Cleanup
On 7/23/06, Stephan Richter <[EMAIL PROTECTED]> wrote: The point is that at least zpl.py contains always the latest header, i.e. corrected year or owner. I can count on it being correct. Only so long as someone remembers to update them. These files aren't really project-specific, either; maybe it makes more sense to have a separate "project" in the repository just for the templates, and those who find them useful can get (and update) them easily, without leaving them as droppings in the Zope source tree. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: NAG NAG NAG (Was: Let's have a bug day -- sort of)
On 8/11/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Actually, talking about 683: I once noticed that Zope 3 is declaring 'zope' as a namespace package the setuputils way where as Zope 2 does it the pkg_util way. I wonder which one is the one we should stick with? I think the right thing for the zope package is to use the setuptools way if setuptools is available, but use pkgutil if not. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/dublincore/ Dublin Core property to use Dublin Core meta data as simple properties.
On 8/14/06, Jürgen Kartnaller <[EMAIL PROTECTED]> wrote: It definitely doesn't obsolete the existing implementation. DCProperty is the other way around. DCProperty allows access to DC meta data via simple properties. I agree that these should co-exist. I'm not sure just what motivated DCProperty, but it's clearly different from the partial adapter. The motivation for theh partial adapter was that for some content, some of the data fields correspond directly to DC elements. For those, we wanted the DC adapter to use the fields instead of storing the information outside the object. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
On 8/19/06, Lennart Regebro <[EMAIL PROTECTED]> wrote: Nothing. But when we have loads of empty top level packages that each have a couple of modules it gets confusing, since you need to keep track of what does which. This is a perception problem, which indicates a documentation problem. Each of the separate packages is in a top-level project in Subversion, so worry about the top-level namespace a red herring. The issue is that there are a lot of individual packages, and it's hard to keep track of so many in your head at once if you haven't really used them. An I'm guess no one has used *all* of the Zope 3 packages on svn.zope.org at this point. I would much more prefer if we could keep all small useful packages in some sort of kommon namespace, which we know holds loads of small useful packages. If this in unfeasible, then fine, I'll just have to live with it. I guess what I'm getting at is that it's not the top-level packages we need to worry about, but the packages themselves. Those are what offer interesting functionality that we want to consider for re-use in applications. Seems to me what we need is a way to easily find a list of what's available, with concise human-readable descriptions of what each does. There are a options to consider: - The Python Package Index (PyPI) has framework categories. I thought Jim had requested one for Zope 3, but I see only Paste and TurboGears in the currently published list. We can get the appropriate category added to PyPI and use that for browsing the available Zope 3 component offerings. This would also make Zope 3 activity visible to the rest of the Python community. - There's a mostly-ignored Zope 3 wiki on dev.zope.org that could be used more effectively. Adding a page to act as a catalog of what's available is straightforward and keeps the barrier to entry low. This doesn't offer the visibility or other features that PyPI offers, however. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
On 8/21/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: I'm +1 too, but I'm against naming this category Zope 3. I would just call it Zope. Two reasons: I think this should be a community decision. While my own interests are largely limited to Zope 3 these days, the increasing overlap makes the distinction less meaningful. I don't expect to spend my time arguing which is best. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZSCP?
On 8/21/06, Stephan Richter <[EMAIL PROTECTED]> wrote: Zope Software Certification Process I wrote a lengthy proposal in February and March. The public thread starts here: I'll admit I've only looked very briefly at the documentation you've produced so far. My initial reaction is strongly based on the use of the word "Certification". That tells me this involves evaluation and judgement of software, not just tools that allow me to locate software that may be interesting. I'm not saying that such evaluation isn't valuable, but... it's a big jump to go from a finding tool to packaged evaluation criteria. This discussion seems to be largely concerned with finding tools. I think it's perfectly reasonable to have multiple finding tools, each with their own policies for inclusion. I think there's also an important distinction between a certification process and tools which help automate the process. I hope these are clearly delineated in your documentation; I'll keep an eye out for that the next time I've time to look at those. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Timedelta widget?
Has anyone created a widget for the zope.schema.Timedelta field? I'd love to see one that's available under the ZPL about now. :-) -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c vs. the zorg
On 8/24/06, Benji York <[EMAIL PROTECTED]> wrote: If "zc" were to become "zope community", I'd be *totally* for it (but I don't speak for ZC here, so that may not be cool with others, like say Jim). We'd either keep using "zc" under the new meaning, or switch to something else. "z3c" clearly stands for the Zope Zoftware Zystems Consortium, so should be freely used by the Z3C's members according to the usage rules established by that august body. The rest of us shouldn't be wasting time worrying about it. I'm sorry. It's off my chest now, so if this (mercifully) peters out soon, we'll all be better off. Indeed. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
On 8/25/06, Michael Kerrin <[EMAIL PROTECTED]> wrote: What name should I use, I have seen a lot of talk on this but never really followed any of the threads to the end. If you say use X I will. I don't want to start another thread on this. I think the name is fine. There are packages under zope that don't get checked out as core, too, so no need to change it. Ignore the namespace packages arguments, those are decoys. Exactly. If you need a feature that is only in lxml, just importing lxml is probable the right thing to do. Yes. I think a wrapper that understands what versions of ElementTree might be available and that implement the basic ElementTree API makes sense. With the introduction of xml.etree in Python 2.5, the number of possible spellings goes up yet again. Moving all the import cruft to a single place makes sense. I will note that Zope 3 doesn't even come close to being happy with Python 2.5. I don't have time to work on that, and a number of discussions are probably needed to work everything out. I should start a wiki page with notes on what needs to change, but that's a separate discussion. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.etree comments
On 8/25/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: also wonder how easy it is to install something that's not shipped with the core into the core. From where I sit (behind fancy buildout systems!), it's just as easy to add another separately-developed zope.something package as it is to add a zc.something package. There are a number of non-core zope.something packages on svn.zope.org now, and these definately see use in one or more projects. Yes, that makes sense, if you have a need to rely on one library or another for the same API. I'm not sure whether this is an important need, though... One could say this anticipates Python 2.5, but once Python 2.5 is released and Zope starts to require it, making zope.webdav use it could be as simple as just changing a few import statements anyway. "Use" are "require" are distinct. We probably want to support Python 2.5 before we require it. That would be ideal, at any rate. My interest is in keeping all the import dances out of application code; I find them terribly distracting, and keeping the reasoning behind specific aspects of such a dance straight can be difficult. This isolates it from the application, avoiding duplication of the import dance. That said, it's probably also valuable *not* to exclude lxml.etree from the dance so that applications don't accidentally become dependent on the extended functionality. Or it could be wrapped to prevent access to additional features, but that seems overkill. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
On 9/5/06, Jim Fulton <[EMAIL PROTECTED]> wrote: On the subject of the style guide, I think that, given that Python has adopted the underscore-naming scheme, we should do the same. Just as with Python, it would *not* be necessary to conform existing APIs to a new style. Hmm. The Z3 style guide has never matched the Python style guide completely, and I think it would do more damage than good to change it. We adopted some things early on in Z3 development that I think helped, but changing it just because more is covered in the Python style guide seems arbitrary. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Patching zope.testing
On 9/5/06, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote: runner (is anyone else using it?). We're certainly using the zope.testing framework for internal projects; I expect a number of projects would be affected. In thinking about this, it's not at all clear to me that this is the "right" thing to do. When checking logging output, what's really being checked is that a usable log entry is being made at the right level. If what you want is to test an exception, that seems to be a distinct test (IMO, of course). -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
On 9/5/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: When I remember right, then I read an important sentence in the Python style guide -- something along the lines: "This is a guide: you should follow it but there are occasions when you may not do so with good reasons." I don't know if this means you agree or not. I don't think this paragraph really applies to this discussion. Jim suggested that we change the Z3 style guide, and I'm suggesting that that's counter-productive. Clearly, existing code isn't affected immediately, and APIs can't be changed anyway. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: So, in the end, a new style guide would only apply to new packages or new APIs, which are mostly outside of the Zope 3 core nowadays anyways. Yes; this I understand. My point was that there's no reason to change the Z3 style guide, even just for new code/packages. Sounds like that's what was agreed on in #zope3-dev as well, so we're ok. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Functional testing of XML-RPC views
On 9/19/06, Stephan Richter <[EMAIL PROTECTED]> wrote: This is perfectly fine. The exact XML was never of interest. I think this is right for most cases. Sometimes it may be (especially in the case of reported bugs and error handling), but I think that's an unusual situation. Those cases can continue to use http() without problems. I'm +1 on merging the branch as well. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.selenium, Selenium 0.7.1 bug
Hi all,
The zc.selenium package includes Selenium 0.7.1 (the latest release),
which includes this unresolved issue:
http://jira.openqa.org/browse/SRC-99
This impacts one of our projects, and the workaround described avoids
the problem. It's not clear that the workaround is more than that (or
that it's not). Is anyone else affected by this? Does the workaround
have a negative impact for anyone?
I've attached a patch against zc.selenium that implements the
workaround. I'd like to commit this in zc.selenium if there are no
objections.
-Fred
--
Fred L. Drake, Jr.
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
Index: resources/scripts/selenium-browserbot.js
===
--- resources/scripts/selenium-browserbot.js (revision 70236)
+++ resources/scripts/selenium-browserbot.js (working copy)
@@ -997,7 +997,9 @@
triggerEvent(element, 'change', true);
}
+/* See http://jira.openqa.org/browse/SRC-99
triggerEvent(element, 'blur', false);
+*/
}
catch (e) {
// If the page is unloading, we may get a "Permission denied" or "Unspecified error".
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: the maintenance of change logs
On 9/22/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Right. Or in old-skool distutils world, you can use a setup.cfg file: http://docs.python.org/dist/setup-config.html Oddly, the setup.cfg file is not used as a source for much of the metadata passed to the setup() function, AFAICT. The documented structure certainly suggests that only arguments to specific commands can be represented in that file. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: the maintenance of change logs
On 9/22/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Actually, I was recently told that one of the advantages of JARs are that the META-INF data is actually more easily read and written than the EGG-INFO stuff. Again, I'm pretending not to know much here ;) Might be; that I don't know. I know META-INF is just a directory, but I don't remember anything about the file formats. And I don't think I've ever really looked at what EGG-INFO is. Given time, I'd like to keep it that way. ;-) -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Grrr. zope.org wikis are evil.
I've mostly learned to stay away from the wikis on zope.org, but some days, I just forget. I use a lot of wikis. And I like them, really. They're good for many applications, and the Zope 3 development wiki, while disorganized and somewhat dated, isn't really any worse than others. Until you want to update it. The edit form provides no link to help on markup, and there really aren't many wikis I use that use StructuredText, so I forget the details of syntax. There's also no way to preview changes before committing. That's a big problem. I think the zope.org wikis are the only public wikis I use that don't support previews. So whatever the ZF's plans for dealing with zope.org, I think there's no way to go wrong with the wikis except by keeping what we have now. While it's nice to use a Zope-based solution, I think we need to just get a solution that works. That could be a Zope 2 installation with a recent version of ZWiki, or something else (MoinMoin would make me happy as well, and has good reStructuredText support these days). So has anyone released a nice Zope 3 wiki yet? I might be interested. :-) Yeah, I'm grumbling. It's Friday night, and I've had it with the archaic StructuredText. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Grrr. zope.org wikis are evil.
On 10/7/06, Jim Fulton <[EMAIL PROTECTED]> wrote: There's a Zope 3 port of zwiki. There's http://svn.zope.org/zwiki/. I just checked it out into a Zope 3 trunk checkout, added in a bit of configuration, and poked at it. My first impression is that it's more than a little raw. - HTML WYSIWYG Wikis that don't use any form os structures text (small s) and just use an HTML editor. I think that structured text of any kind is an obstacle to Wiki use. Moin moin's markup rules drive me as batty as old Structured Text drives other people. ZWiki supports EPOZ editing and I'd love to see that used. Of course, this sort of experience avoids the need for preview or structured-text documentation. Didn't someone write one like this for Z3? Possibly as part of a zope3.org thing? I now vaguely recall something being done, but that's about all I remember. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/ Fixed encoding of newlines, carriage returns, and tabs when
On 10/20/06, Baiju M <[EMAIL PROTECTED]> wrote: So, we have to merge this to 3.2 and 3.3 branches? I just done this in my check out and test with Python 2.4.4 and 2.4.3 versions, all tests passed. Can I commit it? Thanks! I ported this to 3.2 and 3.3 branches. Untill the next point releases, some tests will be failed when using Python 2.4.4 . So, we have to make new point releases now? They'll be needed at some point, I guess, but when they should be made depends in part on the release manager. I don't know that this alone constitutes sufficient reason for a release. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.i18n dependency in zope.configuration
On 10/21/06, Baiju M <[EMAIL PROTECTED]> wrote: I was looking at zope.configuration source, zope.i18n is given as a dependency in DEPENDENCIES.cfg, but it is not imported anywhere in that package. So, can I remove 'zope.i18n' line from DEPENDENCIES.cfg file? It looks like zope.i18n can go, but the simpler zope.i18nmessageid needs to be added (done on the trunk). Maintenance branches should be checked for similar updates. Thanks! -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope Configuration Processing and Side Effects
On 10/21/06, Simon Michael <[EMAIL PROTECTED]> wrote: How do you feel about this folks ? I'd like to make the old zope 3 wiki read-only and activate the subscriptions on the new one. A small but good step forward from the present situation of two identical writable wikis. The new wiki is much nicer to work with; thanks, Simon! -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.i18n dependency in zope.configuration
On 10/22/06, Baiju M <[EMAIL PROTECTED]> wrote: So any module imported should be added as a dependency. Then, what about modules imported in test files (*.txt or test*.py files) ? Pretty much; there are cases where a package might import something conditionally in order to improve integration, but if it isn't available, the package as a whole can function just fine on its own. In those cases, no dependency should be recorded. Ideally, dependencies of the implementation and the tests should be separated, but we've been treating them as one so far. Moving to eggs should allow improvements along these lines. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Fwd: [Zope3-dev] Re: RFC: Zope Configuration Egg Support
Resending; something went wrong along the way... -- Forwarded message -- From: Fred Drake <[EMAIL PROTECTED]> Date: Oct 23, 2006 9:44 AM Subject: Re: [Zope3-dev] Re: RFC: Zope Configuration Egg Support To: Jim Fulton <[EMAIL PROTECTED]> Cc: Rocky Burt <[EMAIL PROTECTED]>, Zope 3 Development On 10/23/06, Jim Fulton <[EMAIL PROTECTED]> wrote: Perhaps we should change the package option so that it uses the pkg_resources API to load ZCML files from packages. There are still cases where egg != package that would need to be addressed specifically. There's this draft proposal; I guess it's time for me to finish this: http://zope3.zwiki.org/ZIPImportSupportForZope3 This reflects work I did at the Goldegg packaging sprint in San Jose. The changes from the branch should be easy to move forward if people agree that it's a reasonable approach. It offers the advantages that 1) there's already code, with tests, and 2) it works with all imports from ZIP files, not just eggs. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca -- -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Fwd: Re: RFC: Zope Configuration Egg Support
On 10/23/06, Jim Fulton <[EMAIL PROTECTED]> wrote: I assume that this is directed at Fred and the ZIPImportSupportForZope3. The code needed for resource loading from ZIP files or other packages that provide the right __loader__ interfaces is pretty minimal. pkg_resources includes a lot of other stuff. In an egg-rich environment, it's reasonable to rely on pkg_resources, but it looked like just another dependency at the time. I just tried the pkg_resources from setuptools 0.6c3, and the resources APIs work for non-egg packages, including conventional directory-based packages and ZIP files that aren't eggs, so there's no reason we can't use pkg_resources if we're willing to live with the dependency. (Just checking everything we use into the Zope 3 repository isn't a pattern I want to encourage.) I think we need to think harder about the file-access API. I expect there are improvements to the API that could be made, as well as to the implementation. I'm not sure what the point of making file references string subclasses is. This is done so that code that hasn't been modified to to work with file references (to support backward compatibility); in the case of applications that contain only non-zipped packages (egg or otherwise), the string-based references can be passed directly to open() or other Python APIs that take strings, exactly as they are today. Some other questions on the file-resource API: - What is the basepath argument to the new method used for? This is used to compute a final path, and is most important when resolving references from ZCML that does not have a package context. - What is the "context" of the caller to packageReference? The intent is that code that creates objects such as the ViewPageTemplateFile or anything else that creates objects that store filenames for later use. The packageReference constructor captures the package information from the calling context, returning a reference that can be used later, possibly by code that isn't filereference aware. Finally, we need to be able to deal with some cases that pkg_resources will deal with that I think the API you used won't, namely: - setuptools namespace packages, and I'm not sure about this; it might not support that case. I'd have to write a test to be sure. - loading from eggs who's names are not package names. I'm not sure what this is about; I'd have to dive in again to even understand what -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Fwd: Re: RFC: Zope Configuration Egg Support
On 10/24/06, Jim Fulton <[EMAIL PROTECTED]> wrote: I certainly don't want you to check setuptools into the repository. Certainly not! For pkg_resources, we don't need setuptools. setuptools depends on pkg_resources. But this brings up a good point. In the future, I want dependencies handled via eggs, rather than by including them into the respository. We have a little bit of a python and egg problem here. ;) We need setuptools to leverage eggs and we need eggs to leverage setuptools. I guess we need to porceed in the following fashion. 1. Create a buildout-based Zope 3 project using non-zipped eggs. This should be a separate project than the current Zope 3 project. 2. Once we have the buildout-based project working to our satisfaction, we can introduce the dependency of zope.configuration on setuptools and start converting eggs to be zip-safe. As I noted, there's no need to depend on setuptools, only on pkg_resources. There shouldn't be a requirement on setuptools for runtime behavior at all. I don't see a need to proceed in this order. Whether Zope 3 itself uses eggs for it's own dependencies is independent of whether eggs of other application dependencies can be used. The work from the sprint allows Zope components, including configuration, templates, and other resources, to be pulled from zipped eggs. > in the case of > applications that contain only non-zipped packages (egg or otherwise), > the string-based references can be passed directly to open() or other > Python APIs that take strings, exactly as they are today. I think this is a mistake that will lead to subtle, or at least, confusing bugs. Then we have some backward compatibility issues to think about. > The intent is that code that creates objects such as the > ViewPageTemplateFile or anything else that creates objects that store > filenames for later use. That's not a sentence. :) Ouch! No more late-night emailing for me. The intent is that code that creates objects that hold on to paths be able to pass in a file reference that will "work" regardless of whether the code it is passed to understands file references. The code need not be concerned with whether it is contained in an egg, zipped or otherwise. If the code using the file reference uses the zope.filereference APIs, the reference can be handled even if the provider is in a zipped package. In many cases (not all), this is useful for things like defining views that use ViewPageTemplateFile or similar constructs. >> Finally, we need to be able to deal with some cases that pkg_resources >> will deal with that I think the API you used won't, namely: >> >> - setuptools namespace packages, and > > I'm not sure about this; it might not support that case. I'd have to > write a test to be sure. setuptools namespace packages aren't allowed to contain data files. That's fine; if there can't be any data files to load, nothing will be found. Sounds like this is supported to me. ;-) So you can't read data by package. You can read data from an egg. I suggest instead that we ignore this use case, at least for now. Agreed. I don't see that we have a real use-case for non-package-related data from eggs. That's also something where eggs and conventional directory-based data handling are substantially different, as are the use cases. I don't see that we have any need to worry about those cases in something like file references at this time. If we want to pursue this in the near future, there are a couple of things that are needed: - We need to decide if we want to commit pkg_resources.py to the Zope 3 repository, or otherwise decide how to deal with the dependency. - The changes on the branch need to be ported to work on the trunk (shouldn't been too much work). zope.filereference still doesn't address the larger issue of breaking apart what's in the Zope 3 repository and assembling the dependencies from eggs or other separate packages. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] The z3c.javascript package
Is the "z3c.javascript" package intended to be a namespace package itself, or is it a conventional package? -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The z3c.javascript package
On 10/24/06, Fred Drake <[EMAIL PROTECTED]> wrote: Is the "z3c.javascript" package intended to be a namespace package itself, or is it a conventional package? Hmm. After I asked this, Gary pointed out that the package doesn't actually provide the MochiKit/dojo/... content; there's some undocumented expectation that those come from elsewhere. My first guess is that this is a licensing-related issue; is that right? I think the expected usage/buildout pattern needs to be documented. (I have a general desire to retire an internal package we've been using with something that's shared, but this only makes sense if the community package is documented.) -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Tracking eggification of zope.* packages
On 11/6/06, Baiju M <[EMAIL PROTECTED]> wrote: We have to use test layers for functional testing with at least one layer per package based on ZCMLLayer ? Then there will be TestBroserLayer, PublisherLayer etc. or should we create a ZopeAppServerLayer derived from ZCMLLayer and use it for the packages where application server is required to run tests? Any package that needs to register anything beyond this basic ZopeAppServerLayer will need to define a new layer. Running the tests like that can take time, since the layers take time to build, but isolating the components is worth while, since it makes it easier to re-combine components in different ways, so the only tests that are needed for the integration are those that test the integration itself. Where do we place zope.app.* individual packages in subversion? If we are placing it in toplevel (under main) there will be about 90+ packages. What about creating a 'zope.app' directory in toplevel and put all zope.app.* packages there ? I see no reason to introduce a new convention at this point; there's already a long list of packages at the top level, several more won't make it less convenient. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
On 11/10/06, yuppie <[EMAIL PROTECTED]> wrote:
While pointing the label to the div element that contains the input
fields is not very useful, this seems to be valid HTML::
Sorry for not replying earlier, but I wanted to have time to think
before responding. ;)
There's valid according to the DTD (the XML definition of validity),
and there's valid according to the specification. DTDs aren't able to
specify the constraint documented in the specification document; in
this case, that means the DTD can be used to help detect invalid HTML
documents, but not determine whether an HTML document is valid. More
expressive schema languages could be used to produce a more useful
schema definition.
Given that the specification clearly states that the "for" attribute's
value be an ID for a control, I must conclude that referring to the ID
of a or other non-control element causes the HTML to be invalid.
Making sure that radio and checkbox widgets have a div tag with the
required ID is a simple bugfix. No API changes are required and
zope.formlib still can use the widget name in the 'for' attribute.
Regardless of the HTML specification, this is a semantic change in the
contract of the IWidget API. So it's a change, just not in the set of
attributes and methods and their signatures.
So IBrowserWidget's __call__ method *has to* return a snipped that
contains a tag with the widget's name as ID. All widgets that don't
follow that rule have to be fixed.
If there are no objections, I'll make the required changes on 3.2
branch, 3.3 branch and trunk.
I object; this is still a change to the contract.
You were on the right track with your first proposal. There's a need
for widgets to provide more information to support integration in a
form. Unfortunately, adding an attribute to the IWidget or other
existing interfaces doesn't work well, since it makes it harder to
write code that supports multiple versions of Zope.
Another way to expose the required information is to create a new
interface and provide adapters for the existing widgets (possibly by
simply implementing the new interface on the existing widgets). A
form that's aware of the new interface can use the additional
information.
The new interface could look something like this:
class IWidgetControlInformation(zope.interface.Interface):
labelControlId = zope.schema.TextLine(
title=_("Label control id"),
description=_("Id of the control element that should be"
" associated with any element rendered"
" for the widget."),
required=False,
)
focusControlId = zope.schema.TextLine(
title=_("Focus control id"),
description=_("Id of the control element that should be"
" focused when the form is initially rendered."
" Since each widget may suggest an element for"
" the initial focus, this should only be regarded"
" as a hint."),
required=False,
)
-Fred
--
Fred L. Drake, Jr.
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
On 11/11/06, yuppie <[EMAIL PROTECTED]> wrote: Well. I can't see why Zope 3 has to ship with two completely different implementations of widget rows and I don't like the formlib template either. But this is not the code that causes validation errors. I can't say that I like any of the form-generating templates, but I'm not convinced there's a solid generic solution. The formlib template was good enough for some projects, but we use another for the project I'm working on now, and that one's pretty unsatisfactory as well. Good forms are hard to generalize, IMO. AFAICS the biggest problem are the poorly maintained widgets in zope.app.form. Poorly maintained? I don't think that's it. While many were developed quickly and are questionable, a lot of the problem is the interfaces. They just aren't conducive to building robust forms. We need a better interface, and I suspect we need to think about the ways we build forms, and how we want to build them, before we can really do any better. Many of us have put thought into better ways to deal with widgets and forms, but finding the time to work something out is hard to do; we're all busy. Often we have to live with partial solutions. Philipp: * we now explicitly state a contract that has been assumed implicitly before yuppie: I think this would be the case if we choose the more pragmatic solution. Maybe. There are certainly some assumptions in the way the current forms are being generated (both with zope.formlib and zope.app.form), but it's not clear that the label id assumption is all that widely agreed upon. This looks like overkill to me. No use case comes to my mind where focusControlId would be different to labelControlId. That depends on what it means to suggest that a particular control to be focused. I'd expect that you don't want to suggest one normally, and let the form determine whether it should focus the first control identified with the labelControlId or not. If something like the focusControlId were defined (as part of the contract) to be set when the identified control is involved in fixing an input error, it makes a lot more sense to have both. If there's an error, focusing the first widget involved in correcting the error makes a lot more sense than focusing the first widget. Whatever such things are intended to be used for, it should be described explicitly in the interface contract. I'd say people don't care about the specs as long as validators and browsers don't complain. But maybe this is too pragmatic. Some people care and some don't. The framework should not stand in the way of those who do. Those who don't also won't care that the framework doesn't force them to ignore the specifications; they can do that on their own. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] should schema.Date accectp datetime values
On 11/14/06, Bernd Dorn <[EMAIL PROTECTED]> wrote: i just saw that zope.schema.Date objects accept datetime values because the default validate implementation uses isinstance to check the value. this is a problem imho, because datetime is a subclass of date but instances can't be compmared to each other. Agreed. any problems with this? and if no, is it ok to backport it to 3.3 I don't know. It seems like a bug to me, but I'm no bastion of backward-compatibility. i also tried using type instead of instance in the base implementation of the validate method, but this affects i18n messages, because they are not unicode. The implementation is sensitive, I suppose. The patch you include looks fine to me. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Bugday today
On 11/16/06, Jeff Shell <[EMAIL PROTECTED]> wrote: Any status report on this? The collector state(s) seem unchanged. The collector is software. For some reason, it doesn't seem to want to work for me at least. It's possible that this capriciousness on the part of the collector isn't just aimed at me. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Display widget for IText and ITextLine
On 12/19/06, Stephan Richter <[EMAIL PROTECTED]> wrote: I Would consider it a bug or at least a mis-feature, if a display widget could render hidden values. You can easily solve this problem better using sessions. There are some corners here. To support hidden form input (especially if a form field can move back and forth between hidden and visible, which I think is an interesting and useful case), there needs to be *some* way of setting the current input aside. Using hidden input fields is one way, and sessions are another. In either case, the original input must be handled by the input widget, since only it understands what controls it is using. The current approach is to use the hidden() method on input widgets. Changing this to allow different ways of setting the input data aside must still rely on the input widget providing the data and a way to restore the data to the widget. This is not available in the current API for input widgets. If we had this, we could get rid of the hidden() method. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Jeff Shell <[EMAIL PROTECTED]> wrote: If TAL / Page Templates isn't really made available to anyone else, how could it get momentum? 'zope.tal', 'zope.tales' and 'zope.pagetemplate' could probably be combined into a nice world-usable egg. zope.pagetemplate is used in JOTWeb: http://jotweb.tummy.com/ I'm sure there are others using zope.pagetemplate & friends. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On 1/6/07, Martin Aspeli <[EMAIL PROTECTED]> wrote: Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. The only issue here is whether Zope 3 itself is useful directly to end users, or something built on top (regardless of whether that's the OFS or something else). The issue that seems to be slightly controversial is whether the Zope 3 core developers should be responsible for that application. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. I think we're all in agreement on this. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: formlib: spurious viewspace slot?
On 1/11/07, Thomas Lotze <[EMAIL PROTECTED]> wrote: Why do you think your concerns regarding changes to formlib don't apply with the skin? Perhaps because most people don't use Rotterdam for client-visible work? Conceptually, the same issue is there. > Does it work if you rename the div id in the Rotterdam skin template and > CSS? In our case, yes, but we have to touch our own CSS as well. Which leads me to the conclusion that other people's products will break on such a renaming as they would have to touch their CSS, too. So the real question becomes, which is a bigger breakage? Using rotterdam + the standard formlib templates is broken because of the duplicate ids, and that should indeed be fixed. Would it be reasonable to remove the id from rotterdam, assuming that fewer projects are impacted, and add a class to both? Using ids is good, but I suspect that every id used in the Zope 3 templates should be unique, just to avoid this. That means a list of ids; there should be a list of classes used as well (including what they're used for). --sigh-- Good HTML design in the face of pluggable pieces is hard. We'd do well to keep these issues in mind as we add new tempates. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
On 1/18/07, Andreas Jung <[EMAIL PROTECTED]> wrote: We're faster with new Zope versions than the W3C with any standard. So? The recommendation for XML 1.1 is already a done deal (a "second edition" was published last September), so there are already multiple specified versions. Since other version strings are allowed, whether there's a published specification or not, we don't want to make assumptions about what's there. How the information should be stored is another matter; my point is only that we can't make any assumptions about it beyond that it's "1.0" if the XML declaration is omitted. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
On 1/24/07, Chris Withers <[EMAIL PROTECTED]> wrote: queryAdapter, for me, is "starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained". o = IFoo(ob, None) if os is not None: ... If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Er, wrong. Like Jim said, if it's documented... -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test layers for zope.app.* packages
On 2/5/07, Baiju M <[EMAIL PROTECTED]> wrote: I have created zope.app egg two weeks back (http://svn.zope.org/zope.app/trunk/) I have used setuptools.find_packages function, so setuptools is a dependency. Should we need compatibility with distutils.core ? I suspect it's fine ok for an egg-supporting setup.py to depend on setuptools, though I'm wary of dependencies outside the Python standard library and our own code for basics. Using zc.buildout ensures setuptools is part of a buildout anyway, so I'll get over my own little hangup pretty quickly. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Test layers for zope.app.* packages
On 2/6/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: An egg should only *depend* on setuptools if it uses things like pkg_resources (e.g. for namespace packages). But there's no need to depend on setuptools for namespace packages generally; that's specific to namespace packages in the presence of zip_safe eggs. This is where I get (somewhat) antsy. That setuptools are required for *building* an egg goes without question. That I've never objected to; I don't want to duplicate that functionality. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.fssync dependency on zope.app.file
On 3/6/07, Baiju M <[EMAIL PROTECTED]> wrote: We have distributed zope.app.file with Zope 3.3 so zope.app.file should be distributed with zope.app egg when Zope 3.4 is released. And we are not distributed zope.fssync with Zope 3.3, but now zope.fssync is dependency for zope.app.file . The only dependencies I see from zope.app.file on any of the fssync stuff comes from the zope.app.file.fssync sub-package; this is intentional. The idea was that that package could be distributed separately; it should be a separate egg from zope.app.file. There are several cases of sub-packages named fssync which should be treated in this way (most of them, in fact); each of the type-specific fssync packages should depend on the package in which they are embedded and on zope.app.fssync. There should be no need to distribute any of them with a stock "Zope 3.4". -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.4 release
On 3/23/07, Baiju M <[EMAIL PROTECTED]> wrote: I think we need not to mimic the zpkg based release for 3.4, rather we should use zpkg for this release also. ... - our 3.4 alpha 1 release date is approaching, we follow time-based release ! But zpkg-based releases aren't a feature; it's just mechanism. Anything that let's us retire zpkg & all the associated cruft is a good thing. I think we are going to stop current way of releasing Zope 3 sooner or later, so we should advocate the use of eggs and zc.buildout for building and deploying Zope 3 applications. Indeed; I don't actually expect to worry about Zope 3 releases again; that's entirely a PR thing at this point. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.4 release
On 3/23/07, Christian Theune <[EMAIL PROTECTED]> wrote: Right. However, I doubt, and Baiju thinks the same AFAICT, that we'll get it done. No reason to delay the release. Yes, that's fine. I've no idea what the release schedule is (and that's deliberate), so whatever works if it's a scheduling issue. Well. Almost. A set of eggs that are tested together has it's advantages as well. ;) OTOH you can do that for your specific app too. In fact, it's only interesting if the set of eggs is a subset of the eggs for the application. For me, much of the Zope 3 distribution is uninteresting. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope3 Standalone Page Templates
On 3/26/07, Jim Fulton <[EMAIL PROTECTED]> wrote: We have a lot of work to do on dependencies. :( Fortunately, a number of community members are working on this right now. We should see some real improvements very soon. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up dependencies for Zope 3.4 eggs
On 4/5/07, Baiju M <[EMAIL PROTECTED]> wrote: Since we almost eggified all packages under zope.app namespace, should we keep the all-in-one zope.app egg ? I've been making it a point to not depend on the zope.app egg; depending on it brings in things I don't want, and that's what we're trying to get away from in the first place. I don't know that unpublishing the already-published versions is needed; they can sit unused forever, and that won't break anything for the people who choose to depend on it. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Releasing Zope 3.4
On 4/10/07, Christian Theune <[EMAIL PROTECTED]> wrote: However, there are currently two bugs assigned to the Zope 3.4a1 release in launchpad that could be moved for the beta unless we feature freeze in the alpha already, I don't remember our policy on that and couldn't find any hint in the wiki. Feature freeze starts at beta1; alphas are for early adopters to kick the tires. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a bug in the Zope 3 (and 2) page template engine
On 4/20/07, kit BLAKE <[EMAIL PROTECTED]> wrote: But those attributes *do* work. If you call that image without the attributes, it won't have a title attribute. If you keep the tag as it is, it will have a title attribute. This is some pretty freaky behavior for page templates, I think, but was by design. (I don't remember the driving use-case though; sorry.) The problem is that Martijn's replacement doesn't start with an element, so the attribute insertion fails. There should probably be a more explanatory error message in this case. I don't really like this behavior, and wouldn't miss it if it were disallowed, but the current expectation is that it work when the replacement starts with an element. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a bug in the Zope 3 (and 2) page template engine
On 4/20/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: No, the current expectation is that it works, whatever the replacement is. This currently works in Zope 2.8: You'll need to explain how silently dropping the tal:attributes on the floor was ever "it works". At any rate, backward compatibility reigns in the page template engine, no matter how misguided I feel this behavior may be. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget(.tiny) widget available to easy_install anywhere?
On 4/20/07, David Pratt <[EMAIL PROTECTED]> wrote: I am not sure why there are two resources for obtaining eggs myself, not sure if it is because pipy gets busy. Should the default be pipy or will this slow buildouts? Maybe all packages could be put there in any case even if primary dependency link for zope packages is download.zope.org. Performance is certainly one reason; PyPI gets its share of aggressive crawlers. Another issue is that PyPI isn't all that interesting for deploying production applications; we need to be able to rely on getting the same set of releases when re-deploying, and we can't do that if someone else is able to hide/remove releases (or the associated downloads), so for longer-term reliability, we all need to maintain a repository of at least the things we expect to be able to get again. pipy already has the infrastructure for some proper searching and management for package maintainers - so not sure that the wheel needs to be invented. For one, "setup.py register" shouldn't always hide other releases; it should be possible to configure that on the client side. Yes, it's possible to have multiple releases visible now, but PyPI makes it unnecessarily tedious. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Separating projects
The "giant Zope 3 checkout" / "shadow project" dichotomy is driving me up the wall. For code that (really) lives in the Zope 3 checkout, it's difficult to deal with separate releases for the shadow projects since the version number should really come from the Zope 3 project. I'm going to move the code for some projects from the Zope 3 tree into the separate projects, and add externals from Zope 3 to those projects. This will allow releases to be handled more sanely. The projects I'm separating are: zope.index zope.app.catalog zope.app.intid While I move the code and add externals to the Zope 3 tree, checkouts will be momentarily broken. I'll send another note when I'm done with these changes. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Separating projects
On 4/26/07, Fred Drake <[EMAIL PROTECTED]> wrote: While I move the code and add externals to the Zope 3 tree, checkouts will be momentarily broken. I'll send another note when I'm done with these changes. Whew! I'm done. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Separating projects
On 4/26/07, Christian Theune <[EMAIL PROTECTED]> wrote: Yay! Is this agreed strategy once on is on the wall? I'm not sure I understand you question. I spoke briefly with Jim today about this issue, and he suggests that for packages that really live within the Zope3 project, they need to share version numbers with Zope3. This imposes all sorts of overhead on the various release managers for the different packages. This makes it very difficult to release the satellite projects in a non-synchronized way. For code that really lives in the "satellite" projects, the satellite projects own the release cycle for that code, and control their own version number. For this reason, it's better to have the code live in the satellite projects, and let the "giant checkout" use externals for them if it needs to. Since I expect the "giant checkout" to rapidly fall out of favor, I'm all for moving code to the satellite projects. Then "Zope 3" will be free to become a swarm of nano-projects that can be assembled into useful but also lean and maintainable applications. Which is what we really care about. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [URGENT] Organising the satellite projects, eggs and version numbers before beta today
On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: I'm in front of the same wall that Fred was going up. ;) And I ran up against a related issue again on Tuesday, which I've not had the time to write up. - Move the code of the remaining projects into the satellite projects. - Replace the satellite's external with the actual code on its trunk and point the Zope 3 trunk back to the package in the satellite project's trunk. +1 -- The sooner, the better. - Create a directory "version" in the Zope 3 tree that holds a "version.txt" file. This will be the common version number that Zope 3 and the satellite projects share. Once the code is in the satellites, there's no reason for them to share version numbers. Ever. They can all start off with "3.4b1", and go from there. The goal is to separate the release cycles. I'm fine with that being "complete" for 3.4 final, but I certainly don't want the satellite projects to be tied to the Zope 3 trunk at all. - Create an external in the satellite projects trunk that points to the version directory in Zope 3's trunk. -1 -- The dependency relationship should be one-way. - Set the version.txt file to read "3.4.0b1". This will always read the next version that is going to be released. - Change the setup.py for the satellite projects to read their version number from version/version.txt -1 -- Just the version number for the satellite, please! In this setting we can develop the satellite projects on their own and make releases that match the code. Tying their version numbers to Zope 3 doesn't affect this. Future releases When releasing Zope 3 "the large project" as beta 1 in this case, following steps would be involved to keep the projects in sync: - Create a release tag on the satellites (tags/3.4.0b1) -1 The branched/tagged Zope 3 should refer to specific tags/branches/revisions of the satellites, but the satellite projects should not be affected by Zope 3 releases. I'll expect to need following scripts: ... - Do a release tag of the Zope 3 tree that includes the mechanics of updating the externals as described in the section 'Future releases' (needed in the future) This should not be needed, because the satellite projects should not be affected by subsequent Zope 3 releases. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [URGENT] Organising the satellite projects, eggs and version numbers before beta today
On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: In a small side note: I still don't know how we recommend using the eggs in a way that says "I want the egg-version of Zope 3.4.0" and the users gets those eggs (and only those) that are synchronised satellites and have "3.4.0" as their version number. I don't think we've defined what "the egg-version of Zope 3.4.0" means (nor do I think we need to as part of a classic zpkg-based Zope 3.4.0). The 'and have "3.4.0" as their version number' I consider a non-goal. Maybe a meta-egg that would introduce the dependency of "zope.xx==3.4.0" as their dependency would allow that to happen because if this gets involved in a working set then the synchronized satellites would be restricted to the exact version. Are you suggesting the satellites would have this dependency? If so, -1. If not, and this is just used as a way of collecting the eggs, I think this isn't valuable, and hence is a decoy. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [URGENT] Organising the satellite projects, eggs and version numbers before beta today
On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: I might have stated my goals the wrong way. I find it valuable to be able to predict which exact versions of things "get pulled in" from a buildout. Me too; that's very, very, very important to me. The current way that dependencies are declared is that when I run buildout in a year I'll get the zope.app.publication-3.5dev-r122 egg on a stable application. I don't want that. I want to again and again and again get the 3.4 egg of zope.app.publication because those eggs where tested together. OTOH. I'm just remembering that Jim talked about some `freeze` feature for buildout ... is that what I seem to want to tackle this issue? ;) Jim's already implemented a "versions" feature in zc.buildout, and I find it immensely helpful. You can set buildout:versions to the name of a section that contains version requirements. Each of those requirements is for an exact version. For example: -- [buildout] versions = versions [versions] feedparser = 4.1 -- When I build this, I get feedparser 4.1 exactly; no other version will show up. I generally "nail down" every version in my buildouts (including buildout recipes), except for software that I'm specifically choosing to track development for (usually application-related), and for deployments, I nail those down as well. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tracking satellite project's trunks
On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: I started moving packages to their own projects (manually right now, preparing for doing this scripted) and noticed that zope.index is tracked with a specific revision number. My understanding is that the trunk of the Zope 3 tree should be tracking the trunk of the satellite project's tree without pinning it to a revision. Probably my fault; I've become really wary of externals that aren't specific. Frankly, I don't *really* care how the Zope 3 tree refers to satellite projects. My hope is that I can very quickly get away from ever looking at the Zope 3 conglomeration (checkout or release), and only use the satellite projects. Conversely, I care very much about the satellite projects not referring to the Zope 3 tree, and look forward to what you're working on today. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tracking satellite project's trunks
On 5/3/07, Christian Theune <[EMAIL PROTECTED]> wrote: Right. However, my suspicion would be that whoever makes a change to the trunk on a satellite shouldn't have to go to the Zope 3 trunk. That's true regardless of how the Zope 3 checkout references the satellite project's code. Also, maintainers of the Zope 3 tree shouldn't have to read every commit message to update the reference (doing so would be pointless, that what not pinning the external is for). That's fine too. The maintainers of the Zope 3 tree simply need to decide how the externals in the tree need to be made. As I said, I don't care which they choose. When moving to a release of Zope 3 we should update those externals to specific revisions or tags though. (Tags being preferred IMHO as we only want software of at least the same degree of stability, right?) That sounds like Zope 3 maintainers want to make decisions about the release cycles of the satellite projects. That's bad. Saying that Zope 3 as a whole is "stable" (whether that's by making a release with an X.Y number or anything else) is about the state of the Zope 3 tree at that point; part of that is an assertion about anything that's included by an external or by a requirement that it's stable as used from Zope 3. It has nothing to do with the release cycle of the independent projects, and should not force a numbering change. It's fine if a new tag is generated, but tags in satellite projects that aren't for that project's release cycle should include the name of the project whose cycle is involved. For example, if there's no zope.index release corresponding to the Zope 3.4b2 release, it's fine to create a Zope-3.4b2 tag of the zope.index project. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tracking satellite project's trunks
On 5/3/07, Tres Seaver <[EMAIL PROTECTED]> wrote: When a truly egg-based Zope3 ships, it should be a meta-egg with explicitly-versioned dependencies. That seems right to me. Approximating that in tree would be to have the Zope3 tree point at *tagged releases* of the satellite projects; revision-stamped versions are a poor (but acceptable in the near-term) substitute. That sounds reasonable to me. Tracking the trunk of any dependency is not acceptable: it undoes the reason for moving the projects out-of-tree in the first place. If we aren't going to do release management on the pieces, then for sanity's sake keep them in-tree. Again, that sounds reasonable to me, but since I've disclaimed caring about the Zope 3 conglomerate checkout/release, I'll not push my thoughts on that on those who do. You're certainly welcome to make the right decision on your own. ;-) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tracking satellite project's trunks
On 5/4/07, Christian Theune <[EMAIL PROTECTED]> wrote: Right. In the last days I felt like in the future we should spend some quality time (maybe face to face at a conference or sprint) to review what happened to the way people work with Zope and how we define it. I think "what's happened" is something very simple, inevitable, and reasonable: We've stopped working on Zope 3 and moved to working on our applications. This changes how we think about the place of Zope 3 in our work more than anything else. It's no longer a product itself, but a means to an end. This is what we intended from the beginning, but the shape we predicted for the result was more similar to Zope 2 than has turned out to be useful. The move to separate "satellite" projects is really a move from using an all-singing, all-dancing framework for all applications to using different sets of libraries for each application based on what's needed for the application. I think this is a good thing. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Usage of actions in zope.formlib ... was: Re: Add flexibility to zope.formlib.form.EditFormBase
On 5/9/07, Maciej Wisniowski <[EMAIL PROTECTED]> wrote: You can have different validators for different actions. If only In fact, it's very important that the validators be separate for different actions, since some actions do very different things (and might not need/want to validate all fields the same way). I know I've written actions that expect to manipulate the form data in some way, based on other data in the form, and then redisplay the form. Most fields would not be expected to validate in this particular case, and only by avoiding the "default" validator could this have been made to work. So while the behavior may seem a little odd, it let's you construct the validation scenarios you need. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Usage of actions in zope.formlib ... was: Re: Add flexibility to zope.formlib.form.EditFormBase
On 5/9/07, Maciej Wisniowski <[EMAIL PROTECTED]> wrote: class MyNewEditForm(EditForm): actions = EditForm.actions ... I mean line: actions = EditForm.actions That's not good enough. ;-) Adding more actions at this point will affect EditForm as well. Better to use actions = EditForm.actions.copy() -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what dependency to use for "zope 3"
On 5/11/07, Chris Withers <[EMAIL PROTECTED]> wrote: I dunno, do we actually need an "offical big zope 3 release" anymore? No. What's more, we don't even want to use one anymore. The value of the big release is more for people who are new to Zope 3, and want to take a look. That's not an audience I'm good at judging, either in terms of guessing what they really want, or in what makes them take that first look. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote: I then feel comfortable sharing the dev Python across builds because I know it is clean. The stuff that gets installed in the system Python's is usually not an issue for Zope applications (I've never had a Zope-related issue with those things), but I always use a clean Python just to be safe in case something odd gets added to the system Python. Ubuntu and the various RedHat-derived systems (Fedora, CentOS) add enough to the system Python that I'd rather avoid them for applications regardless. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On 5/21/07, Reinoud van Leeuwen <[EMAIL PROTECTED]> wrote: As a developer it might be a good idea to have different installed pythons in different environments to be sure that some modules (or python itself) meet different requirements. But as system maintainer I like to keep things simple. I do not want similar trees of python installations all over the place if it can be avoided. That's understandable. I don't think developers want to have extra trees all over the place so much as they want one they can rely on. The system Pythons generally aren't that, since various extra software gets installed there. It may also be built with different settings for things like Unicode character size. We've found it invaluable to have a separate "clean" Python that doesn't have additional packages installed into it (ever), and then our applications can provide what they need without polluting other applications. We can know what options the Python was built with. It also won't be affected by system updates. Once we have such a clean Python, we can share it across however many applications have need of it. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Splitting package configuration
On 5/23/07, Stephan Richter <[EMAIL PROTECTED]> wrote: This solution would not be fully backward-compatible with people including package "configure.zcml" files manually. I think this is okay, since people often do not even want the browser stuff. That's hard to predict; some do, some don't, I don't know where "most" happens to fall. A fully backward solution would be to put all the generic package configuration in a new ZCML file and combine them both in "configure.zcml". However, I find that solution very undesirable, so I hope noone will like it either. :-) I don't like that, but I don't think it's avoidable. I would like to get this change started as soon as possible to make it work for Zope 3.4. If noone objects, I will start with this in a few days. 3.4 is never going to be released, is it? That might bother some people (though not me). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Splitting package configuration
On 5/23/07, Stephan Richter <[EMAIL PROTECTED]> wrote: Thinking about it more, it would actually be backward-compatible, since we never released the packages in themselves but always as part of the Zope 3 bundle. Also, even the packages that are not hooked in via zope.app.zcmlfiles are added via the automated SETUP.cfg stuff. At least this is the official story right now. :-) "Official story" doesn't mean a lot to me these days. I think of individual ZCML files as interface points: someone might reasonably be using them directly (unless the filename starts with an underscore). I hope it is avoidable with the above insight. Again, if you think there's an official story that involves *requiring* people to rely on those nasty slug files, you're deluding yourself. We've always maintained that those are "convenience" (for some definition of "wouldn't you like to shoot yourself in the foot?"). Really? That would be a pitty, because it would allow us to have one release with the old and the new way, so the first people can migrate. Would be a pity, yes, but it'll never happen if we keep changing it. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Splitting package configuration
On 5/23/07, Tres Seaver <[EMAIL PROTECTED]> wrote: Hmm, the use case for slugs was to support "application with separately installed extensions"; Fred, I think your view is prejudiced by the fact that you don't have any need for pluggability / extensibility. Possibly so. I'm certainly not building apps where "drop-in" extensibility is as helpful as others are. Stephan is arguing for finer-grained configurations, which is likely to be better for reuse, at the cost of *reduced* convenience. Yes, and that's fine for me. What I consider an issue is that changing the semantics of is a change to the package's public interface. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] egg version numbers and zope releases
On 5/30/07, Bernd Dorn <[EMAIL PROTECTED]> wrote: Currently nearly all package versions are at 3.4.0b1, which is a big pain when needing to update a package. How so? It's just a number. The real catch is knowing which project owns the number. :-( Would be nice if we had given virgin version numbers to packages such as 1.0. If we now have an update, we need to use something like 3.4.1 and users may think this version is in sync with zope versions. Would have been nice, yes. Would it be possible to revert the revision numbers to 1.0 (we think if they are not in pypi and only on download.zope.org we can delete the releases from there) -1 If we cannot go back to 1.0, what shall we use for intermediate releases? In previous conversations, we posited that the number is "owned" by the project that contains the code. Projects that refer to the code via egg dependencies or svn:externals do not own the version number. Most projects now own their own code, so are free to number things independently from Zope 3. There's been some noise about keeping the numbers in sync through Zope 3 release 3.4.0, though the motivation for that is unclear. I'm all in favor of letting each project do what makes sense separate from Zope 3, and Zope 3 will do what makes sense for it (which has nothing to do with the version numbers of satellite projects). Any project that needs a separate release which does not own its own code should be made to own its code; Zope 3 should not own the code of satellite projects. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
