Re: [Zope3-dev] Re: z3c.widget not on pypi?
On 20.09.2007, at 20:50, Wichert Akkerman wrote: Previously Stefan H. Holek wrote: I fully agree that such eggs should not have been released into the wild. It is just that, down here in real-life, these eggs *have* been released, and their versions *have* been nailed (not nailing the versions of *all* eggs means saying goodbye to the idea of reproducible buildouts). By deleting a released egg (as opposed to superseding it with a good version) one potentially creates a lot of pain for a lot of people. I can fully see a reason to need a private tag or dev-release egg for a project. But you can put those in a private repository for that project. yes, but this was not the case back then when the eggs have been made public available aka released and noone kwows who is using it so if we now decide to not release -dev releases to the public, we can do it in the future, but we have no timemachine to do this in the past :-) the most important point is that production buildouts start failing if you remove the eggs, which costs senseless manhours Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Retire zope.app.boston
On 13.08.2007, at 13:15, Christian Theune wrote: Am Montag, den 13.08.2007, 12:14 +0200 schrieb Bernd Dorn: On 12.08.2007, at 22:55, Roger Ineichen wrote: Hi Christian Betreff: [Zope3-dev] Retire zope.app.boston Please. It's badly tested and I assume widely unused. I tried to fix a bug that was reported for it and it's just a mess. +1, it was more a tryout then a ready to use package. The problem of this package is, it tries to be compatible with the Rotterdam skin. I agree with retire this package. We can do it better if we need an other ZMI replacement. Or is anybody using it? yes we use it, but it should be no problem, because there are already eggs out If somebody is interested using it, I'd be happy to see somebody maintain it. If not we should retire it. Would you care about bug reports made for this package? i think it is ok to retire it, i just wanted to point out that i might be used :-) our administration skin uses it, but the next generation of it will not use it anymore ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Retire zope.app.boston
On 12.08.2007, at 22:55, Roger Ineichen wrote: Hi Christian Betreff: [Zope3-dev] Retire zope.app.boston Please. It's badly tested and I assume widely unused. I tried to fix a bug that was reported for it and it's just a mess. +1, it was more a tryout then a ready to use package. The problem of this package is, it tries to be compatible with the Rotterdam skin. I agree with retire this package. We can do it better if we need an other ZMI replacement. Or is anybody using it? yes we use it, but it should be no problem, because there are already eggs out Regards Roger Ineichen Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
On 02.07.2007, at 20:54, Jim Fulton wrote: See me response to Gary's note. Here's what I propose: 1. We adopt the policy that a distribution's version number must be of less or equal maturity than all of it's dependencies, where maturity is based on it's position in the release cycle. dev is less mature than alpha is less mature than beta is less mature than release candidate is less mature than final. So, for example, dev release of zope.app.keyreference can depend on a dev release of ZODB3, but an alpha release of zope.app.keyreference cannot. Initially, this will be a convention. Eventually, I'll add a feature to buildout to warn when this policy is violated. +1 +10 to the policy violation warning 2. We approach the distutils sig with a feature request for an option to prefer final versions, so that, if we specify the new option, we always get the newest final version that satisfies a requirement, if there is one. I suggest that this be --prefer- final. Anyone want to volunteer to bring this up there? :) I don't think we'll see this feature any time soon. 3. I add a prefer-final option to buildout to prefer final versions. I think I can do this in the next week. what about having some kind of '--min-maturity=beta' where the options are 'dev', 'a', 'b', 'c', 'final' or so i don't know the exact syntax, but we have to take care of the right version syntax, because it seems that there is no policy that defines how maturity levels are defined e.g: x.x.xdev x.x.xax x.x.xbx x.x.xcx we have some packages around that have x.x.x.dev x.x.x-dev and i think they are considered newer than x.x.xa1 Thoughts? Jim On Jun 27, 2007, at 10:01 AM, Christian Theune wrote: Hi, the recent introduction of zope.app.keyreference-3.5dev with it's dependency on ZODB 3.9 brought some issues for me as I get conflicts in various buildouts (e.g. z3c.zalchemy). In my example, z3c.zalchemy doesn't care about which version of zope.app.keyreference it gets, as even the newer one won't affect us. I'd like to re-visit the discussion about stable package versions and how to approach the distutils list to get what we want. Currently I resolve this issue by putting a specific version in my project's buildout and leave the package (e.g. z3c.zalchemy) alone. I'm not sure whether this is the strategy we should use. Should z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our proposed syntax, or 3.5dev with the current syntax)? I'd like to see some consensus on how we handle those ... Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ 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.app.session/zope.minmax
On 03.07.2007, at 09:31, Gary Poster wrote: Christian et al: What do you want in regards to the zope.app.session changes that rely on the new package zope.minmax? Very briefly, the change allows the simple zope.app.session approach to cause fewer unnecessary write conflicts. Is this zope.app.session 3.5dev-rXXX relying on zope.minmax1.0? The other possibilities include pushing it back to 3.4 (probably not, but happy to do it), and calling zope.minmax 3.4 or 3.5. we decided, that satelite project versions are not bound to zope versions, it is actually an accident that the satelites have 3.4xy versions, but we cannot decrease them. so zope.minmax 1.0 is not only ok, it should be versioned that way. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zc.dict/trunk/ Initial version of zc.dict -- a persistent BTree based dict.
On 03.07.2007, at 20:39, Albertas Agejevas wrote: Log message for revision 77375: Initial version of zc.dict -- a persistent BTree based dict. hi this package matches a use-case we have often, very nice! just some thoughts use a BTree.Length object to hold the length, otherwise you will get loads of write conflicts, see also what i have done in zope.app.container this week there is also a small bug in __setitem__ ... if the key exists, the len is increased without a key being added (note, in my zope.app.container this is not the case because you get a duplication error if this happens) you should use __setitem__ internaly for update etc, because computing the length of a btree takes very long time, it has to fetch all buckets from zodb. if u use zeo it gets even slower regards, bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On 26.06.2007, at 21:44, Gary Poster wrote: On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote: On 23.06.2007, at 12:38, Christian Theune wrote: Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster: Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Yes. And if you're at it, I'd welcome if you'd switch the tree's trunk to use that branch. :) The trunk's setup.py of the satellite should either be 3.5.0a1 or 3.5.0. i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status Hi Bernd. Why? because it pulls in software that has development status like zodb 3.9 and the release of 3.9 will take at least a half a year from now on imho. gary, is it possible to be compatible to 3.8 too? Not productively. We could have if the PersistentReference doesn't have the 3.9 stuff then just refuse to do a ConflictError but then that's no different that the keyreference 3.4 behavior. Heh, actually, that's effectively the behavior we probably have now for keyreference 3.5dev running against ZODB 3.8, since errors in the conflict resolution will simply cause the resolution to fail, and the 3.5dev changes would generate AttributeErrors against ZODB 3.8 during conflict resolution. So...it would be a bit of a lie to claim to be compatible with 3.8. The changes are useless without the 3.9 changes. But the code *should* technically work with the same restrictions we have now. That said, I don't really want to support the changes against 3.8. ...I could move the releases to our ZC download location, rather than the zope.org one, if folks want... i don't think that this is a good idea, for example our company uses both of the download locations What's the problem? I'm happy to help, especially if it doesn't take too much time, and you can wait a day or two. ok, i think if another new feature is implemented in keyreference and we want this feature for zodb3.8 we have to do a version inbetween, so if you call this a 3.5 release, what should that other version be? 3.6 we use egg based releases and if you hardcode the zodb 3.9 dependency in setup.py we have to switch to zodb3.9 just because of that package if we want to use a new feature of it maybe i am anticipating here and it's best to make it zodb 3.8 compatible when we need a newer version of keyreference for some reason. the problem with this is, that we (zope committers) can do this, but another company may not be able to change the package. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Specifying upper limits in dependencies
On 27.06.2007, at 16:01, Christian Theune wrote: Hi, the recent introduction of zope.app.keyreference-3.5dev with it's dependency on ZODB 3.9 brought some issues for me as I get conflicts in various buildouts (e.g. z3c.zalchemy). In my example, z3c.zalchemy doesn't care about which version of zope.app.keyreference it gets, as even the newer one won't affect us. I'd like to re-visit the discussion about stable package versions and how to approach the distutils list to get what we want. Currently I resolve this issue by putting a specific version in my project's buildout and leave the package (e.g. z3c.zalchemy) alone. I'm not sure whether this is the strategy we should use. Should z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our proposed syntax, or 3.5dev with the current syntax)? you have to write =3.4.999 afaik, see the previsous discussions. the point is that any new feature should increase the number after the first dot and should be backward compatible with previous versions incompatablities should result in a new major version, so it would be ok to write 3. the problem here is that the update of zope.app.keyreference is introducing indirect incompatiblilities not know yet but still starts with a 3 as mayor version, which is not ok imo because we can not be sure that this change is backward compatible with the 3.4 version. it should be 4.0.0a1 because it switches to zodb 3.9. I already discussed with gary about this in a thread on this list from today. I'd like to see some consensus on how we handle those ... Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On 23.06.2007, at 12:38, Christian Theune wrote: Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster: Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Yes. And if you're at it, I'd welcome if you'd switch the tree's trunk to use that branch. :) The trunk's setup.py of the satellite should either be 3.5.0a1 or 3.5.0. i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status gary, is it possible to be compatible to 3.8 too? The 'dev' is a pre-release tag that is appended while making snapshots or continuous releases. The branch itself should state what the next real release will be. This depends a bit on the policy for each individual package. AS you remember, zope.app.keyreference 3.5.0 may not happen to have anything todo with Zope 3.5 ... Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: AW: publisher performance
On 17.06.2007, at 22:25, Roger Ineichen wrote: Hi Juergen Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jürgen Kartnaller Gesendet: Sonntag, 17. Juni 2007 06:43 An: zope3-dev@zope.org Betreff: [Zope3-dev] Re: AW: publisher performance Roger Ineichen wrote: Hi Jürgen Betreff: [Zope3-dev] publisher performance [...] With this new version I also measured the time with zope as a trunk checkout (no eggs involved). The publisher is now twice as fast as it was before ! I'm writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core. newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher. What do you mean with and without eggs? Do you mean the flat dotted page name structure used in eggs? Does the egg package structure perform different in some way? Or do you mean something else? With without eggs I mean I used a trunk checkout for zope. With eggs I mean I use the eggified packages from zope. Yes, I understand this, but I'm curios about you commit message: checkin 76706 says: Removed stack extraction in newInteraction. When using eggs this is an extremly expensive function. The publisher is now more than 10 times faster when using eggs and about twice as fast with a zope trunk checkout. Why makes this improvment eggs distribution 10 time faster and the trunk only 2 times? Do I get this right? Do we pay the flat dotted package structure, which eggs bring with, pay with slower excecution time? hi roger when it comes to module file introspection like the linenumber extraction in the getStack call, the egg version seems to be slow, because there are a lot more directories on the pythonpath, additionally i can imagine, that the effort to find the file for a module is much higher when having a lot of namespace packages so yes, when tracebacks are generated, the egg version is slower, there might be other places where eggs are slower too, but we didn't find any up till now Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ 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 thought on backward compatibility and minimum versions
On 31.05.2007, at 20:08, Dieter Maurer wrote: I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. i think we are talking about package dependencies here, and not application dependencies if an egg based application e.g zope 3.5 is released, the package versions should be nailed down anyways by buildouts version section and packages should be more tolerant, so that changes of version conflicts gets minimized when collecting them in an application ___ 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: egg version numbers and zope releases
On 30.05.2007, at 20:20, Jim Fulton wrote: maybe it's a good idea to use the same pattern as other distribution/packaging systems. so foo2 or even foo21 is ok if you compare it to the name 'python24' in macports or ubuntu so that means that any incompatible version results in a new package name, so one could be shure to have a compatible version of deps e.g. using things like zope.interface.20 without any version restrictions. I'm not sure what you are suggesting with the zope.interface.20 example. Are you suggesting that this is the twentieth backward- incompatible version of zope.interface? Or that this combines a major and minor version number? the latter ... but after reading through the thread and thinking twice about it, i think that this would not make much sence. it only might be usefull if e.g foo1 and foo2 could live in the same python process (like pythons2.3 and python2.4 can be installed at once) which is not the case. i'd rather stick with the explicit 2.0 2.99 solution ___ 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 10.05.2007, at 10:01, Chris Withers wrote: Hi All, As a newcomer to the world of setuptools, I'm excited by the prospect of automatic dependency handling. However, with the eggification of Zope 3, this leaves me wondering: if I have a package that relies of a certain version of Zope 3, what do I put in as the dependency in setup.py? i guess there will be a meta egg which you would then specify as a dependency for my projects however i just directly set all zope.* dependencies in setup.py explicitly, see the various z3c.* on svn.zopeorg packages as examples cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ 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 11.05.2007, at 17:29, Chris Withers wrote: Fred Drake wrote: 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. cool :-) My only slight concern here is when people make changes in one satellite project, they break another one and don't realise. But I guess the buildbot should catch that, right? i talked with jim about this and we agreed in that specifying versions in eggs is not a good idea. The best way imho is to use buildout's 'version' section in your application's buildout to nail down all eggs to a specific version. 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. Indeed, I'd suggest this is a market best persued by apps like Grok. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 05.04.2007, at 16:23, Stephan Richter wrote: On Thursday 05 April 2007 09:08, Christian Theune wrote: we're starting work on an application that we're going to use Zope 3.4 for and that I'd like to base on the eggs. That should give me the chance to clean up some of the egg dependencies. Yeah, I wanted to look into some dependencies too, since I noticed that zope.pagetemplate will pull in pretty much all of Zope. I think what we need is a tool that draws us a dependency graph. Is there something out there already, at least for creating the dependency graph text version? Since all dependencies are specified as an argument to the setup function, I would not immediately know how to extract that information, except than monkey patching into it. i use this tiny script http://svn.zope.org/z3c.configurator/trunk/importchecker.py? rev=73771view=log and as already mentioned: please forget about the zope.app egg regards, bernd Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ 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 05.04.2007, at 17:34, Stephan Richter wrote: On Thursday 05 April 2007 11:08, Bernd Dorn wrote: i use this tiny script http://svn.zope.org/z3c.configurator/trunk/importchecker.py? rev=73771view=log Right, I know about the importchecker. But it does nto generate the dependency tree for me and is agnostic to optional dependencies, which are supported by setuptools. I really want to hook into the dependencies of the setup script. hm, i think i don't get you ... i use the importchecker to know what i have to put into setup.py the script reports test dependencys seperatly, i have modified it a bit it was very useful for doing the zope.app... packages Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
On 07.03.2007, at 17:37, Christian Theune wrote: Hi, I'm writing up a proposal for the ZODB to make even more efficient Blob handling possible. This includes not copying the data from an uploaded file, but using a `link` operation when possible. However, the Zope 3 publisher currently uses the default implementation of the cgi module's FieldStorage. I propose to create a small subclass to override the `make_file` method to use `NamedTemporaryFile` instead of `TemporaryFile` to allow the file being accessible from a filename so I can apply a `link` operation. Notice: The FieldStorage explicitly provides the `make_file` method to allow overriding in this sense. Does anybody feel like this would be a bad idea? that would be nice, i would prefer to make the whoe FieldStorage class pluggable via a factory interface this is a long outstanding issue for z3c.extfile too, i also wanted to access the file directly greez, bernd Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ 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.mimetype / z3c.filetype
On 07.02.2007, at 03:42, Benji York wrote: Luis De la Parra wrote: I don't know if there is some licesing or some other kind of political issues ( zope vs z3c ), but IMVHO it would be great if the two packages were merged. I'm not really a zope developer yet, but if the maintainers of those packs are interested, I could try to help with that. Interest is abundant; time and motivation are lacking. -- hm, the same problem here currently our company has no time to do this merge, but if you have time, i'll be available if you have questions i am the maintainer of the z3c.filetype package, which is in production use for our projects together with z3c.extfile the main motivation for z3c.filetype was to extract the content type from large binary files without using the file extension information, we use this for media formats, afaik zope.mimetype goes further when it comes to textual content and encodings, but you are right they share a lot. regards, Bernd Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ 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.tal.xmlparser.XMLParser() dislikes unicode
On 13.01.2007, at 18:49, Andreas Jung wrote:
Hi,
the XMLParser.parseString() method raises an exception
File /opt/python-2.4.4/lib/python2.4/unittest.py, line 260, in run
testMethod()
File /Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/
tests/test_xmlparser.py, line 127, in test_xx
self._run_check(xml, ())
File /Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/
tests/test_xmlparser.py, line 106, in _run_check
parser.parseString(source)
File /Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/
xmlparser.py, line 77, in parseString
self.parser.Parse(s, 1)
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 43-48: ordinal not in range(128)
if the string to be parsed is a unicode strings and contains some
non-ascii
chars. The following snippet from a private unittest
(test_xmlparsers.py)
shows the error.
def test_xx(self):
xml = unicode('?xml version=1.0 encoding=utf-8?
fooüöä/foo', 'iso-8859-15')
self._run_check(xml, ())
I am not sure if this behavior is intentional?! Is the XMLParser
supposed
to deal with unicode strings or will it only accept a standard
Python string? A workaround inside parseString() would to check for
unicode
and convert the string on-the-fly to a Python string with utf-8
encoding.
This is possibly a limitation of the underlying Expat parser...any
recommendation how to deal with this issue?
IMHO it should only accept strings, because in the value should be a
xml string and therefore always has to be encoded in 'utf-8' or in
the encoding specified in the processing instruction.
Bernd
Andras
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope-
mailinglist%40mopa.at
___
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 15.11.2006, at 00:39, Fred Drake wrote: 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. for me too, so i checked in the fixes on trunk and 3.3 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] should schema.Date accectp datetime values
hi all 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. so what are you guys thinking about handling this case in schema.Date any problems with this? and if no, is it ok to backport it to 3.3 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. here my diffs, regards Bernd Index: tests/test_date.py === --- tests/test_date.py (revision 70847) +++ tests/test_date.py (working copy) @@ -17,7 +17,7 @@ from unittest import main, makeSuite from zope.schema import Date -from zope.schema.interfaces import RequiredMissing, InvalidValue +from zope.schema.interfaces import RequiredMissing, InvalidValue, WrongType from zope.schema.interfaces import TooSmall, TooBig from zope.schema.tests.test_field import FieldTestBase from datetime import datetime, date @@ -37,6 +37,7 @@ readonly=False, required=False) field.validate(None) field.validate(datetime.now().date()) +self.assertRaises(WrongType, field.validate, datetime.now()) def testValidateRequired(self): field = self._Field_Factory(title=u'Date field', description=u'', Index: _field.py === --- _field.py (revision 70847) +++ _field.py (working copy) @@ -205,6 +205,11 @@ __doc__ = IDate.__doc__ implements(IDate) _type = date + +def _validate(self, value): +super(Date, self)._validate(value) +if isinstance(value, datetime): +raise WrongType(value, self._type) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 23.09.2006, at 06:46, Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) We can create seperate products in launchpad (It can be grouped) for each project. +1 Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] photo/photoslide packages
Hi Darryl On 14.09.2006, at 09:41, Darryl Cousins wrote: Hi all, Is BjornT about? I have been working with photo and photoslide packages - got them working now with 3.3 branch - made resizeUtility schema field a vocabaulary choice Other features I'm beginning on: - make displayIds sizes editable - offer filesystem storage as alternative to zodb please take a look at z3c.extfile and z3c.image for this Regards, Bernd - i18n support for title and description fields (using z3c.language) - translation domain My Zope contributors agreement will be in the mail when I return to NZ on the weekend. The last commit on this package was 20 months ago by BjornT, are there any objections to me developing the package? My changed versions of these packages are available at: svn://treefernwebservices.co.nz/var/svn/tfws.org.nz/trunk/src/photo svn://treefernwebservices.co.nz/var/svn/tfws.org.nz/trunk/src/ photoslide Best regards, Darryl Cousins ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ 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 19.08.2006, at 11:41, Lennart Regebro wrote: I'd like to throw a stick in the fire by taking up a completely different issue: The amount of top level modules and repositories. :-) if lovely.rating depends on schooltool.something, not only does this mean any usage of lovely.rating (which I imagine I would like to use) also needs one module form schooltool. In addition, we have whatever top level module I choose to use. That involves three different repositories, mine, zopes and schooltools, and three new toplevel modules. If I then throw in more modules that have more external dependencies, this will quickly mushroom. For example, I'd like to use ratings and tags with zblog. That means I need to involve the codespeak repository as well, and zblog has it's own top level module. And then I want a discussion forum (I don't think one of those exists) which presumably would have another top level module, and maybe another repository, and maybe more dependencies. The only problem i see here is that there are currently no releases (e.g. eggs) for most of the packages and therefore everybody has to use svn. We should really start to create releases. So, what I'm saying is, that I would like to minimize the amount of top level domains, and external repository dependecies in the zope repo. That said, I think lovely is a lovely name, and don't at all mind having that as a common name for useable little modules like the tag and ratings module. :-) the lovely namespace is from a company called lovelysystems ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] getting started with AJAX
there are packages for zope3 which include javascript libraries you may need http://svn.zope.org/z3c.javascript regards, bernd On 19.05.2006, at 11:45, Sam Stainsby wrote: Hi all, Just wondering what the current status of AJAX in Zope 3 is and how best to get started with it. I believe it would be useful to my work, but I'm not sure where to start. I know work is going on, but not sure what is going to be officially part of Zope 3 and what is just proof-of- concept. I'll probably go with whatever is likely to become part of official Zope 3 or its extensions. My specific interests for the moment are AJAX-enabled widgets, such as a dropdown widget whose vocabulary changes based on the selection in a different dropdown within the same form. I don't want to pre-cache all possible vocabs, since there could be a quite a few large vocabs in my application. Perhaps there is a better way to do it, but I don't want to reload the entire page to update the widget. It is an accounting/inventory application that requires fast data entry. Any tips on how to get a Zope 3 sandbox into s state where I can do this sort of thing, and any specific tips for AJAXifying widgets? Cheers, Sam. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] pytz daylight savings bug?
Hello
I don't know if should put this on the zope3 tracker or somewhere
else so i post it to the list too.
in pytz the daylight savings are not correctly returned by the dst()
methods, i looked into the source code and saw that the passed in
datetime is ignored imho this should be used to get the utc offset at
that given datetime. the same applies to utcoffset()
example which fails:
import pytz
from datetime import datetime
import time
tz = pytz.timezone('Europe/Vienna')
dt = datetime(2006,5,30,12,tzinfo=tz)
dt2 = datetime(2006,1,30,12,tzinfo=tz)
assert(dt.dst()!=dt2.dst())
___
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: The browser:page compromise
On 25.04.2006, at 20:27, Lennart Regebro wrote: At https://svn.z3lab.org/z3lab/hello/trunk there is now a page this url seems to be broken implementation that is easy to use and doens't do class generation. In fact, there are two versions, one that sets the __call__ attribute during instantiation, and one that uses browserDefault() and publishTraverse(). There is also an implementation of a template directive, that can be used for view-less templates, like Philipps implementation. It also has no class generation, but instead uses one empty view-class as a placeholder for all view-less templates. A pages directive for multiple pages is coming, and will possibly replace the page directive completely, to avoid uneccesary duplication. Comments are welcome. (If you don't want to check it out and test it, you can browse the code here: http://svn.z3lab.org/trac/z3lab/browser/hello/trunk/ ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ 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: The browser:page compromise
On 20.04.2006, at 18:56, Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise I've long been thinking about how to make browser:page / simpler and less magical. Some radical ideas weren't received well and I couldn't convince even myself 100% that they were the way to go. Other brainstormings were dead ends. I therefore call this proposal a compromise. It simplifies, but it shouldn't annoy (Tres...). Note that I'm specifically only addressing browser:page /, not browser:view /; nor am I coming up with a framework for dealing with forms and their handlers (Jeff...). 'Nuff said. Your turn :) -1 In the Proposal you say: Why is this a problem? Because certain behaviour is mixed into the class created on-the-fly. This behaviour is not apparent in our view class, yet we assume it exists. It's magic. For me this is not a reason to change/add directives. This just results in more work for keeping track with the zope3 releases in client-projects. It is ok to improve things, but this is no improvement for end users IMHO. This reminds me of the deprecation of the vocabulary directive, which is also just a burden for end users (i've missed that discussion). and: Browser pages are essentially just adapters to the Component Architecture. Implementation details (template or not, etc.) should not be of much interest during the registration. I don't think that the template is an implementation detail. IMHO For a high level user the adapters are an implementation detail. Regards, Bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.datetimewidget and ITZInfo request adapter
hello guys from zc is there an implementation of the adapter from request to ITZInfo you use in zc.datetimewidget for example in http://svn.zope.org/zc.datetimewidget/trunk/src/zc/ datetimewidget/datetimewidget.py?rev=41765view=auto ... tzinfo = ITZInfo(request, None) ... if not, what would be the prefered way to implement such an adapter thx, bernd ___ 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 plan for widgets?
On 17.03.2006, at 10:32, Martijn Faassen wrote: One problem I seem to have is that I cannot find the mailing list to subscribe to to find checkin messages to the zc package. Is there any? the normal checkin list is [EMAIL PROTECTED], but not all packages are included (i think only core packages), and i dunno the policy behind afaik jim is responsible to configure from which packages checkin messages are sent to this list ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with multiple instances of zope3 as daemon via init script on gentoo
On 11.01.2006, at 14:27, Jim Washington wrote: Bernd Dorn wrote: hi all i have two init scripts (see below) which start a zope3 instance this works fine if i start one of them, but if i try to start the second, the following message appears * Starting Zope in /home/zope1/timetables ... WARNING! zdrun is managing a different program! our program = ['/home/zope1/timetables/bin/runzope'] daemon's args = ['/home/zope1/screens/bin/runzope'] daemon process already running; pid=10839 seems that the pid of the other instance is taken, does anybody know how to solve this or is there another way to start zope3 as an unprivileged user? as far as i know there is no effective-user directive in zope.conf as in zope2 Does this script put a zdsock file in /etc/init.d? I have noticed that the zdsock file is created in the directory where zopectl is called. If this is what you are seeing, one solution might be to do some cd statements (e.g., cd $INSTANCE_HOME) so that multiple zdsock files are created, one for each instance. thx, you brought me on the right track! it is actually a problem with the default zdaemon.conf in zopeskel, where socket-name is just set to zdsock this will be placed in the working directory, which in my case was the home directory of the user because of the - switch to su so i added the following line to zdaemon.conf: socket-name $DATADIR/zopectlsock, which this is the behavior of zope 2 skel i would say this is a bug, because instances created with mkzopeinstance can not be run in parallel additionally with socket-name set to zdsock one is unable to run zopectl as root, because then the socket gets created in the home of root where the user the daemon is running on has no access. this leads to an access denied error. the init script is now the same as with zope2, i can just call zopectl directly without suing to the zope user i will fix this in the trunk thx, bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with multiple instances of zope3 as daemon via init script on gentoo
On 11.01.2006, at 15:42, Bernd Dorn wrote: On 11.01.2006, at 14:27, Jim Washington wrote: Bernd Dorn wrote: hi all i have two init scripts (see below) which start a zope3 instance this works fine if i start one of them, but if i try to start the second, the following message appears * Starting Zope in /home/zope1/timetables ... WARNING! zdrun is managing a different program! our program = ['/home/zope1/timetables/bin/runzope'] daemon's args = ['/home/zope1/screens/bin/runzope'] daemon process already running; pid=10839 seems that the pid of the other instance is taken, does anybody know how to solve this or is there another way to start zope3 as an unprivileged user? as far as i know there is no effective-user directive in zope.conf as in zope2 Does this script put a zdsock file in /etc/init.d? I have noticed that the zdsock file is created in the directory where zopectl is called. If this is what you are seeing, one solution might be to do some cd statements (e.g., cd $INSTANCE_HOME) so that multiple zdsock files are created, one for each instance. thx, you brought me on the right track! it is actually a problem with the default zdaemon.conf in zopeskel, where socket-name is just set to zdsock this will be placed in the working directory, which in my case was the home directory of the user because of the - switch to su so i added the following line to zdaemon.conf: socket-name $DATADIR/zopectlsock, which this is the behavior of zope 2 skel i would say this is a bug, because instances created with mkzopeinstance can not be run in parallel additionally with socket-name set to zdsock one is unable to run zopectl as root, because then the socket gets created in the home of root where the user the daemon is running on has no access. this leads to an access denied error. the init script is now the same as with zope2, i can just call zopectl directly without suing to the zope user i will fix this in the trunk done see: http://svn.zope.org/Zope3/trunk/zopeskel/etc/ zdaemon.conf.in?rev=41267view=rev ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] initial checkin of cxoracleda
On 20.10.2005, at 14:13, Stephan Richter wrote:
On Wednesday 19 October 2005 16:26, Bernd Dorn wrote:
it is tested against 3.0 and 3.1 versions of zope
see: http://svn.zope.org/cxoracleda/
Note that if you create a SETUP.cfg file, the ZCML slug, i.e.
cxoracleda-configure.zcml, is automatically installed in the
package-includes
directory. This is the recommended way of doing things these days.
Eventually, you should also use zpkgtools to create your package, of
course. ;-)
hi stphan,
that's actually the next step i wanted to do, but i have to look at
the zpgk stuff before
another question:
in my testcase http://svn.zope.org/cxoracleda/trunk/tests/
test_adapter.py?rev=39515view=auto
i need to somehow get the connection information from a property
file, is this the right way to do this
i do this like this::
import os
propFile = os.path.join(os.environ.get('HOME'),etc/zope/cxoracleda/
testproperties.py)
try:
execfile(propFile)
except:
raise Local property file not found,propFile
this is a problem i think for automated tests etc.
any sugestions ?
thx, bernd
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] initial checkin of cxoracleda
For anyone who is interested in connecting zope3 to oracle I checked in an Oracle DB Adapter to the zope repository which is using the cx_oracle library http://www.computronix.com/ utilities.shtml#Oracle it is tested against 3.0 and 3.1 versions of zope see: http://svn.zope.org/cxoracleda/ Any feedback is welcome ... Best Regards, Bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] i18n translate tal:contents not translated
hello list if i do this in a page template: div tal:attributes=title python:u'Title' i18n:attributes=title i18n:translate= tal:content=python:u'Title' i18n:domain=zope/ div i18n:translate= i18n:domain=zopeTitle/div the content of the first div gets not translated, but second does, also the title attribute gets translated is this a bug thx, Bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [EMAIL PROTECTED] address not working
This address is not working when sending a mail to: [EMAIL PROTECTED] (Zope CVS administration [EMAIL PROTECTED]) i get... Your message To: Zope CVS administration Subject: Re: Commit privileges for zope source code repositories Sent:Thu, 22 Sep 2005 07:18:22 +0200 did not reach the following recipient(s): [EMAIL PROTECTED] on Thu, 22 Sep 2005 07:23:50 +0200 The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator. digicool.com #5.0.0 Reporting-MTA: dns; ride.ad.uclv.net Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 X-Supplementary-Info: digicool.com #5.0.0 X-Display-Name: [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
