Re: [Zope-dev] Zope 4 release management
On 11/17/2011 07:01 PM, Martin Aspeli wrote: I would actually argue that "Zope4" have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. -1 - we'll need something to amalgamate this into a release and we'll need a way to manage and number those releases. I agree; actually "ZTK-like tracking set" is really already talking about doing releases, just like the ZTK has releases. And just like ZTK releases do, this needs some release management effort. Now I would advocate that Zope 4 releases mimic the ZTK in the way things are managed. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] congrats on the new zope.org launch, but..
On 07/15/2011 03:13 PM, Hanno Schlichting wrote: > On Fri, Jul 15, 2011 at 1:50 PM, Martijn Faassen > wrote: >> I'd just call the category "web framework"; 2 out of 3 already say they >> are. Zope can then itself say in its description that it's an >> application server if that's an important term. > > At least zope2.zope.org uses the "web framework" term to describe Zope > 2 as well. "application server" doesn't describe todays Zope 2 > codebase and aim anymore either. > > So I'd rather place all of the "big guys" in the "web framework" box. +1 Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] congrats on the new zope.org launch, but..
Hey, On 07/11/2011 06:09 PM, Andreas Jung wrote: >> According to zope.org Gork is more like ZPT than it is >> like BlueBream. Griok is more like CMF than it is like BlueBream. This >> is because Grok is listed under the grab-bag framework category. > > I partly agree with you - I think Grok can be considered both as an > application server and as a framework. I would not object to move Grok > to the app server section if you want it. +1 > The problem is more that > grab-bag "framework". The "ZCA" is to be honest not a framework but a > concept and "ZPT" is a part of the "ZTK" and all other frameworks. Yeah, it's a grab bag item, I already mentioned that previously, but I still think Grok should be in the same category with BlueBream. We can look up my previous post to see what I suggested about the framework category there; I did offer some suggestions there. >> I also mention that 'Application Servers' may not be the best heading >> for the category which could contain Zope and BlueBream and Grok. Zope's >> an application server, the other two are called "web framework" > > I won't start a new philosophical discussion about differences between > application servers and web-frameworks - any better naming suggestion > for a category holding Zope, Bluebream and Grok? I'd just call the category "web framework"; 2 out of 3 already say they are. Zope can then itself say in its description that it's an application server if that's an important term. It's still a compromise but I think it's better to compromise towards "web framework" which is the more recognizable term. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] congrats on the new zope.org launch, but..
Hi there, Congrats on the relaunch of zope.org, I know it's been a hard slog! But I brought up an item twice already and nothing appears to have been done about it. According to zope.org Gork is more like ZPT than it is like BlueBream. Griok is more like CMF than it is like BlueBream. This is because Grok is listed under the grab-bag framework category. I also mention that 'Application Servers' may not be the best heading for the category which could contain Zope and BlueBream and Grok. Zope's an application server, the other two are called "web framework" I really think it's obvious that this is wrong, so, please fix, thanks. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 07/05/2011 12:22 PM, Jonas Meurer wrote: >> Since we don't market Zope2 anymore, I think there's actually much >> less confusion from this than we'd fear. It's just an internal version >> number used in some buildout files, not something that has any >> particular meaning. > > I don't like either of these solutions. And I don't agree with Hanno, > that it's 'just an internal version number'. It will show up on > zope.org, launchpad.net, and many more places. > > I would rather bump the version number to 2.20 to highlight the major > changes, and keep the 2 as major for Zope2 versions. I agree calling it Zope 2 version 3 would be very confusing. There's a lot of Zope 3 google juice around that would get muddled up even more. Concerning not marketing Zope 2, heh, Zope and marketing strategies? I thought we were going to call "Zope 2", "Zope" now, so people will obviously be curious about this Zope thing... Never make any assumptions about a coherent Zope marketing strategy! I'll also drop in a reference to the existence of zope2.zope.org. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)
Hi there, http://beta.zope.org/the-world-of-zope dekade -> decade: And just talk about 'Zope community has grown' instead of starting with "Zope Corp. and the Zope community", which I think gives the impression the community is some kind of appendage to Zope corp, the driving force behind it all. While this was true 10 years ago, it isn't today. And Zope corp is a part of the Zope community, right? And we're not talking about Zope corp specific products either, so that could lead to confusion the other way: somebody might call Zope corp about Plone. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)
Hi there,
On 05/10/2011 06:55 AM, Andreas Jung wrote:
> Constructive criticism and feedback is welcome _now_.
Application servers has Zope & BlueBream.
Then Grok's at the bottom under 'Frameworks' together with CMF, Repoze,
ZCA, ZTK and ZPT.
Grok is most like BlueBream and should be in a category with BlueBream.
If Grok's a framework so's BlueBream.
I'd call 'Application servers', which is mostly a term from Java land,
"web frameworks" instead, because that's what Python developers will
understand, and put Zope, BlueBream and Grok under it. If it sorts
alphabetically (frameworks seems to do so) and Grok comes first, I don't
mind. :)
Just think about whether Zope stuff is more like this:
http://en.wikipedia.org/wiki/Application_server
or more like this:
http://en.wikipedia.org/wiki/Web_framework
The Frameworks entry seems like a total grab bag to me ("I didn't know
where to put this"), which is why I wouldn't want Grok presented that
way. But you'd need to split up 'Frameworks' really.
ZCA and ZPT can be successfully presented as libraries (framework-style
libraries perhaps, but they're just libraries you can install and use),
and ZTK is a collection of libraries (which in fact contains the former
two libraries).
I'd say make a new heading:
Zope Toolkit
Put under it:
* ZCA
* ZPT
* other Zope toolkit libraries
So we're highlighting two important libraries and say we have a lot
more, managed within the ZTK.
You can put CMF and Repoze under Frameworks if you wish.
But a question: do we really want to present CMF as a current framework
that people can use to start projects on? If not, and it's legacy only,
should we really present it as an entry point? I'm not sure where Repoze
would go in all this though.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test fixture concepts
On 03/29/2011 02:43 PM, Wichert Akkerman wrote: > On 3/29/11 14:40 , Stephan Richter wrote: >> >> Yeah, Marius led me recently to that path too. Write a narrative in text >> files >> and use doc strings of functions to do edge cases (or when you don't have >> time >> for the narrative). I am getting used to it. I still much prefer the sort of >> output comparison that doctests/manuel gives me over the assertion language >> that unittest.TestCase requires. > > FWIW unittest2 has much nicer output if you use the new assert methods. py.test has very nice output if you use the Python 'assert' statement. There are no assert methods to remember. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test fixture concepts
On 03/27/2011 05:13 PM, Martin Aspeli wrote: > On 27 March 2011 15:54, Uli Fouquet wrote: > >> The (limited) experiences with py.test, however, were awesome. Some >> points that are quite cool IMHO: >> >> - Easy finding of tests: just write some ``test_function`` in a >> ``test_module`` and it will be found and executed. That also makes >> py.test tests more readable and maybe more intuitive. > > I'm not sure this is always a good idea. It feels a bit implicit, and > having a base class isn't really a big problem, IMHO. It seems a bit > like the kind of thing that sounds cool (look, it's even easier!), but > in practice makes little difference. Belatedly adding my few cents here: in practice I quite enjoy not having to copy ugly boilerplate from test modules that I always always forget. It's actually nice to just write a test_* function and have the test runner just work. So it's cool for some people, namely me. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] fanstatic and preprocessors
Hey, [snip Wolfgang] >> [1] >> http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html >> [2] https://github.com/sstephenson/sprockets Thanks for these links! We should investigate Sprockets to see what other features it has, and perhaps in the future collaborate with them on a packaging format. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope test layers, pytest, and test isolation
Hi there, [extensive introduction by Uli of zope.pytest] Thanks Uli for that introduction to the package and its problems! I've been using zope.pytest within 2 Grok projects so far to test through webob some JSON webservices, and it's worked well for me. I hadn't had to deal with the issue of multiple configurations in those tests though, as they're basically functional/integration tests. I've also been happily using plain py.test in several other non-Zope projects, and I must say it has many nice features that make life easier, and makes a lot of test cruft go away. I'm particularly hoping that Wolfgang Schnerring will give feedback: I'm curious how his investigations on improving the layer story might also benefit py.test integration. Regards, Martijn P.S. Uli did a lot of work himself to make this package and help document it, by the way, he's doing himself injustice in his introduction. :) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Hi there, It is my understanding that the ZTK is primarily to adopt proven solutions that arise from our community that we intend to be shared by this community. I'll also note that Martian is already in use in combination with Bluebream, Zope 2 and Grok. With that, I was thinking, concerning alternative configuration mechanisms I think we should have: * a clear statement of use cases concerning configuration. * a weighing of the importance of these use cases, underlying reasons, etc. * an evaluation whether Martian or Venusian can fulfill those use cases. * if use cases are found that Martian or Venusian cannot fulfill, then an evaluation whether these can be made to fulfill them by modifying them. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 04:08 PM, Jim Fulton wrote: > On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen > wrote: >> On 03/21/2011 03:28 PM, Jim Fulton wrote: >>> I don't know what the right answer is ... at least not yet. :) >> >> In Django and sqlalchemy declarative a meta class is used for this kind >> of configuration. Since that is subclassing, it implies inheritance, I >> think. > > Ick. > >> Of course metaclasses are not very good for this as they're surprising >> in other ways > > Agreed. Martian allows you to use a similar spelling to metaclasses (base classes), without the weird surprises during run-time (after configuration is already done), and without significant import-time side-effects. With megrok.rdb I actually use SQLAlchemy declarative without their declarative metaclass, as the SQLAlchemy folks were kind enough to tweak their config code so I could call it directly from a grokker. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:28 PM, Jim Fulton wrote: > I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Of course metaclasses are not very good for this as they're surprising in other ways and use unstructured configuration happening at import time. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:07 PM, Lennart Regebro wrote: > On Mon, Mar 21, 2011 at 14:17, Martijn Faassen wrote: >> Anyway, Grok's configuration is dependent on the rules you give it, so >> it's possible to have a completely explicit set of directives with no >> implicit fallback to default values whatsoever. Martian supports that >> scenario right now. > > Sure, but I'm of course referring to how it behaves by default, > including the associations made by the grokking process. > I think that makes sense in a webapp, but not otherwise, and we should > at least as a start concentrate on the generic component architecture > case. > >> For Martian, Python 3 support is mostly an issue of making class >> directives work as class decorators. > > And the same goes for zope.component support, of course. We have a much more extensive directive abstraction though. That should make it harder and easier at the same time. :) > With martian, the registration is then done by the grokking process, > but I think decorators would be a process that is more acceptable to > the Python world in general. Instances does indeed require something > else than decorators, I hadn't thought of that, that's a drawback. Do we really care about "the Python world in general"? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. You'll still need a module importing process, as I sketched out elsewhere, if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Note that we do support function decorators with Martian. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Hi there, On 03/20/2011 05:47 PM, Hanno Schlichting wrote: > Maybe there's something in Grok that comes close to this. I've just > not been able to distinguish the "Grok the web framework" code with > its convention over configuration idea from some basic explicit > configuration approach. I don't understand. Venusian took its ideas from Martian, and Martian's not a web framework and never has been. http://pypi.python.org/pypi/martian Surely you've heard of this library before? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Hi there,
On 03/20/2011 04:00 PM, Hanno Schlichting wrote:
> Taking one of the examples of grokcore.component, I think there's a
> lot that can be made simpler:
>
> import grokcore.component
> from zope.i18n.interfaces import ITranslationDomain
>
> class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
> grokcore.component.implements(ITranslationDomain)
> grokcore.component.name('helloworld')
>
> Based on my Pyramid exposure, I'd write this as something like:
>
> from something import utility
> from zope.i18n.interfaces import ITranslationDomain
>
> @utility(ITranslationDomain, name='helloworld')
> class HelloWorldTranslationDomain(object):
> pass
It's interesting to consider inheritance rules here. What if you
subclass from HelloWorldTranslationDomain? What happens to name and the
interface that the utility is provided under?
I'm not saying I know the right rules for inheritance in all cases, or
that grokcore.component is sane here, but I know in some cases having
directive values inherit is pretty neat, and in some cases it isn't. I
imagine registration can always be explicit, however.
Note also that if we're simply talking spelling, this makes grok a bit
shorter and is the way Grok code typically looks:
import grokcore.component as grok
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grok.GlobalUtility):
grok.implements(ITranslationDomain)
grok.name('helloworld')
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 03/20/2011 04:29 PM, Jim Fulton wrote: > On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting wrote: [snip] >> I think you cannot avoid this, if you want to support an explicit >> configuration phase. Otherwise the first import of a module could >> occur at any point at runtime and have a configuration side-effect >> like registering a new view. Personally I find the venusian approach >> pretty simple and explicit enough. > > I disagree. First, the notion that you'd import at run time is pretty odd, > unless you count start-up in "runtime". You might have a module that you don't import at all, but does define components you want to be wired up. How is this module going to be registered? You could import it after all in some module you *know* is going to be imported (which one?). It seems rather easy to make a mistake here and wonder why things don't get configured. Plus you're importing stuff that you then don't use. > Second, well, really, I'm not ready to give up on a straightforward > definition of wiring that doesn't rely on module scanning. You could do the wiring using class decorator side effects, but the module will still need to be touched to get the decorators to kick in. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 03/21/2011 10:17 AM, Jan-Wijbrand Kolman wrote: >> - scanning can take a long time, making application (re)start slow for >> non-trivial projects > > At what point is an application not trivial anymore? In applications I > build so far, startup time has not been an issue at all. But maybe my > applications are still on the trivial-end of the spectrum ;) In general we haven't really gotten much feedback about this being a performance issue, as far as I know. The modules need to be imported at some point anyway so we don't really add much overhead there, and otherwise it's just going through the module's attributes, which I imagine comes down to looping through a dictionary really and doing a lot of isinstance and issubclass calls. That's going to be pretty fast. It might even be faster than ZCML XML parsing, it's hard to say. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Hi, On 03/20/2011 03:28 PM, Jim Fulton wrote: > Hm, it's been a while since I've looked at grok. Some notes: We have more than four years of experience with this topic... > - The mechanism I'm thinking of should not require *any* ZCML. Check. we just bootstrap the grokking process from ZCML right now. We use zope.configuration actions to be compatible with ZCML. > - The mechanism shouldn't require something to "grok"/analyze the >code. The mechanism should be explicit. This is implied by >"pythonic". I remember Grok being more implicit than skimming the >links above suggest. Perhaps Grok has has become more explicit than >I remember. The basic principles are still the same. We still import code and grok those classes/instances/functions we want to do something with. Now that we have class decorators we could come up with another collection mechanism however. That said, you'd still need to import the modules at some point, otherwise collection will not take place as the decorators don't get executed in the first place. Martian has been expanded a lot though. I recommend looking at Martian. > - I'd prefer not to rely on subclassing, but I'm not dead set against it. Class decorators might work. Subclassing does have some nice properties though; it feels Python and it becomes easy to come up with your own domain specific base classes. But it's not a major gain over class decorators I imagine. Note that if you do directives on classes at all, you're going to have to think about how subclassing interacts with configuration. 'implements' is a good example of that. > - Whataever we come up with has to work with Python 3, so >unfortunately, we can't use the syntactic trick of having a call in a >class like:: > > grokcore.component.implements(IContentProvider) > > The effort should certainly include an analysis of approaches like > grok. Maybe the mechanism should have the effect of enabling tools > like grok to be implemented more cleanly. Yeah, a nice project would be to let Grok use class decorators instead of old style traceback-exploiting class directives. We have a fairly well defined directive mechanism which knows about inheritance. It even knows about module-level directives that affect all classes in the module and then those classes have subclasses. > Note that the move from "advice-based" syntax to class decorators > provides a good opportunity to revisit how some of this works based > on experience using the ztk. I'm not sure how the behavior would be affected based on experience. For 'implements' for example, we still want subclassing behavior, don't we, decorator or not. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 03/20/2011 02:31 PM, Jim Fulton wrote: > On Sat, Mar 19, 2011 at 5:02 PM, Lennart Regebro wrote: >> Getting ZCA/ZTK to run on PyPy is probably easier, and actually more >> useful. Maybe someone would want to mentor that? > > This is another porting project. If I was a student, I wouldn't find it very > interesting to port some code I hadn't written and probably don't > understand from > one platform to another. (My earlier comment on py2k->py3k porting wasn't > meant > as a dig against py3k bit rather to say that I didn't think porting > projects would > be very interesting.) That's true, we had bad experience with the Jython project a few years ago. It depends on the students though; I think we had better experience with a project to move Zope 2 forward to a newer version of Python 2.x (if I recall that correctly). But writing new code is a lot more fun. But if you're going to do porting, PyPy is a lot more tempting as a target for me. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 03/19/2011 10:02 PM, Lennart Regebro wrote: > Getting ZCA/ZTK to run on PyPy is probably easier, and actually more > useful. Maybe someone would want to mentor that? I agree it'd be easier and more useful. There's also interesting potential in exploiting PyPy's magic in things like security and ZODB persistence. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Hi there, For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. I'm not sure what Lennart means by point 1. Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. The only implicit behavior left would be the grokking process, which generally recognizes subclasses of particular base classes as something to register. You could do away with this using class decorators as well, but that would require some changes to Martian to allow it to recognize things that way. (and it won't work for grokking instances, just classes and functions) Note that Pyramid as far as I understand also has a non-ZCML configuration method that is closer to ZCML. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PyPy 1.4.1 and the ZTK
Hi there, On 12/22/2010 09:56 PM, Chris McDonough wrote: > FWIW, for our web stuff I've found PyPy to be about 3X as slow as > CPython (even allowing for the JIT to warm up). But the elephant > dances! Any clue what's taking up the time? Do you think it's simply that it doesn't speed up zope.interface to the level of the C version? I vaguely recall something about PyPy's JIT not being good with interpreter-style patterns in code - so that might slow down things if templating is involved. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PyPy 1.4.1 and the ZTK
Hi there, I thought it'd be interesting to note that PyPy 1.4.1 (with JIT) now works out of the box with buildout (at least if I use the '-d' option for distribute with bootstrap.py, but I suspect plain setuptools also works). I actually added a few compatibility fixes to buildout the other day that are now unnecessary: PyPy 1.4.1 adds the compatibility with released versions of buildout out of the box. This makes it possible to start testing some of the ZTK with PyPy. There are challenges of course: certain packages, such as zope.interface, use C extensions and would need to be installed in "plain-python" mode (if available). The ZODB would definitely be an interesting challenge too. One snag is that PyPy is only compatible up to Python 2.5. This might make some of the code fail. Then again, if it's the 'with' statement the fix is an "from __future__ import with_statement" away. A release of PyPy with Python 2.7 support is still a while away, but being worked on. The benefit of using PyPy? It has a JIT on board, so that should speed up some code significantly. Whether it'll speed up some of our tests is hard to say though - the JIT might be more overhead than gain in that case. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Toolkit 1.0 release
On 10/13/2010 05:57 PM, Jan-Wijbrand Kolman wrote: > On behalf of the Zope Toolkit release team and the Zope community, I'm > happy to announce the release of Zope Toolkit version 1.0! Congrats to the ZTK release team! Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK & Windows support
Hi there, I've heard some noises from people that might or might not indicate something about the status of Windows support in the ZTK. If support would be dropped, let me just say that this would be a problem for me, a ZTK consumer. I personally have customers that deploy Grok on Windows (as a desktop application). Eventually I'll want to upgrade that software to a version of Grok that use the ZTK. It's also a problem for Grok. Grok tries to support Windows. Grok is best served in general if people can run it on Windows to at least try things out. I am making a request as a consumer of the ZTK that Windows support is to be taken somewhat seriously. And no, I'm not stepping up to do the work. But perhaps this thread can serve as a positive starting point for those who do. Regards, Martijn P.S. I realize that work to support Windows is being done by several people, including Hanno. Thanks! ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml dependency in Zope 2.12.10 KGS
Hi there, On 09/10/2010 04:01 PM, Martin Aspeli wrote: > When the software breaks, people go elsewhere. I didn't say Windows > support was easy, or any fun. But we have to decide: do we care about > people who have made (or are forced to make) different technology > choices than us, or do we tell them their platform is unsupported? If you don't provide good Windows support and leave it to people who supposedly do care, you're setting yourself up for a self-fulfilling prophecy; the Windows people will not be there in the first place. And you're *lucky* as a project if you hear from people who have trouble installing it. Most people who have trouble installing your problem will just silently move on to something else. It makes sense to listen to these people very carefully when they are there, and even to anticipate what they might desire - if it's something as obvious as Windows support. It might also help to just go and read the lxml mailing list. As I see Laurence just said, Sidnei was talking about working on this very topic just 4 days ago... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml dependency in Zope 2.12.10 KGS
Hi there, On 09/10/2010 03:04 PM, Hanno Schlichting wrote: > This is unfortunate, but really a problem for the lxml community and > not us. So the lxml community cannot keep up with providing binary > Windows eggs. This cannot force us to stick with old and buggy > versions of the software. I might make sense to just email Sidnei. He's been responsible for the lxml windows eggs for years, and he's been doing some Zope egg work too. I.e. if you have a problem with lxml, it might make sense to just talk with the lxml people... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] docs.zope.org automation
On 08/02/2010 06:34 PM, Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/2/10 18:26 , Martijn Faassen wrote: >> http://packages.python.org/distribute/pkg_resources.html >> >> You can probably create a Distribution object somehow (handwave) from a >> path (whether that's the path of the package or the path the package is >> in, not sure). > > The issue, just like with pkginfo.Develop, is that I can't find any > function or method that finds package information in subfolders. If you > look at... > > http://packages.python.org/distribute/pkg_resources.html#getting-or-creating-distributions > > ...there's this function find_distributions which supposedly offers > subfolder searching, but it just doesn't work. At least it doesn't do > what I would expect when I read the documentation. It finds nothing. Yeah, unfortunately this is generally the point where I find myself being lost too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] docs.zope.org automation
On 08/02/2010 05:25 PM, Jens Vagelpohl wrote:
>> python setup.py --long-description
>
> Can someone tell me how to do that when I am in Python code already?
> Given the path to the checkout, can I use some setuptools/pkg_resources
> or pkginfo magic to get at this data?
Oh, this is where I always get scared because I always get lost. :)
The pkg_resources documentation is here:
http://packages.python.org/distribute/pkg_resources.html
You can probably create a Distribution object somehow (handwave) from a
path (whether that's the path of the package or the path the package is
in, not sure).
Then maybe 'get_metadata('long_description') on the distribution object,
but maybe not as one seems to have to supply metadata when constructing
a distribution..
But again, I always get lost here, perhaps you need an Environment or a
WorkingSet first, etc.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] docs.zope.org automation
On 08/02/2010 04:53 PM, Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/2/10 16:50 , Stephan Richter wrote: >> On Monday, August 02, 2010, Stephan Richter wrote: >>> py26 setup.py --long-description | rst2html >>> >>> rst2html have many options that allow you to modify the style, including >>> the ability to specify a stylesheet. >> >> Oh, btw, this is also the method that we used to verify that the long >> descriptions are proper ReST. ;-) > > I hereby declare that verifying proper ReST is OUT OF SCOPE for > docs.zope.org ;-) It's out of scope for PyPI too, what it does is just display the plain text if there are any ReST errors. And when the developer sees that, that's a clue to go and fix the ReST and use the above technique. So as long as there's a clue that "it's not working" we'll be fine. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] docs.zope.org automation
On 07/31/2010 07:22 PM, Jens Vagelpohl wrote: > Here's a followup on a docs.zope.org automation task I took over during > one of the Zope developer IRC metings[1]. The task was to provide > individual package documentation, if it exists, directly underneath > docs.zope.org, e.g.: > > http://docs.zope.org/zope.event/ Really cool! Wouldn't it be good to put this under /package/zope.event to avoid potential naming conflicts? I realize they're rare, but I can imagine that a project foo could exist that wants to expose its documentation separately from project foo. Perhaps "Zope" would be a good example. :) Regards, Martijn P.S. It'd be good if the ZODB section had at least a link to zodb.org. Links to buildout.org and grok.zope.org might also be useful. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Can ZTK 1.0 support Python 2.7?
On 07/13/2010 02:12 PM, Hanno Schlichting wrote: > Given all of these, I'm leaning towards not supporting Python 2.7 for > a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to > support 2.7 in addition. +1 For Zope standards we'd still be very fast with supporting Python 2.7 if we do this (assuming 1.1 will be out before, say, 2012 :). Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Including Paste into the ZTK version list?
On 07/09/2010 04:50 PM, Hanno Schlichting wrote: > I noticed that all three frameworks (BB, Grok, Zope2) have version > pins for Paste, PasteDeploy and PasteScript. Does anyone object to > including them into the ztk-versions.cfg under dependencies? No objections from Grok. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.traversing's ILocation behavior
Hey, [zope.traversing absolute URL behavior] I've applied the fix to zope.traversing and added a test as well. It's released as zope.traversing. I've also updated the ZTK to use this version. (initially I used checkversions to update a few other packages too, namely zope.dublincore, zope.index, zope.pagetemplate and zope.testing, but this *did* result in zopeapp breakages, so I reverted that quickly. Someone needs to look into this to see what can be upgraded and what causes the break later) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.traversing's ILocation behavior
Hi there, in zope.traversing.browser.absoluteurl there was a change a while back that breaks my code, now that I'm upgrading to it. The code in the absolute URL generation code used to be this: container = getattr(context, '__parent__', None) This simply gets the __parent__ of the context so that it can ask for its absolute URL. If no container can be found the answer will be None and the system will raise a TypeError, complaining about insufficient context. The code was then changed to this: context = ILocation(context, context) container = getattr(context, '__parent__', None) While this code looks initially confusing, what it does is try to adapt context to ILocation, but if it fails, falls back to 'context' to look up parent, preserving backwards compatibility but adding the feature that people can register custom ILocation adapters for models. But then, in dependency work by Christian Theune, the code got changed to this: context = ILocation(context) container = getattr(context, '__parent__', None) In addition, in zope.location an adapter got added for everything (Interface) that creates a LocationProxy. This means that the ILocation adaptation *always* succeeds, and might return a location proxy with __parent__ and __name__ set to None. This rather confused me initially, as this is one of those magic transparent proxies (except for __parent__ and __name__!). 'context' has a __parent__ *until* the point where ILocation() is called on it, and then the proxied context suddenly loses it __parent__! This broke the behavior of code that relied on __parent__ being checked first. I realize that this was depending implicit behavior, as models don't *really* provide ILocation. But on the other hand working code is broken in a really obscure way. The fix in my code was to make my model provide ILocation itself, so that it would adapt itself and therefore avoid the proxy. I think that might be correct but at the same time is really obscure; in my code the __parent__ is provided by a completely different subsystem (traject). Models that didn't provide ILocation used to work, and now they fail. Do we really want to require everybody to start providing ILocation in all their models? I propose the following adjustment: try: container = context.__parent__ except AttributeError: container = ILocation(context).__parent__ So, try to find the __parent__ the old way first, without adapter lookup. If that fails because the attribute is missing, look up the adapter. That might get one the proxy again, but at least not when a __parent__ is actually available. Still, this deserves some commenting for future people trying to debug what's going on. I've verified that at least in my application this unbreaks the code. I'll also try to add a test that demonstrates the expected behaviors so that this doesn't get broken again. Opinions? Regards, Martijn P.S. I want a publisher with location support but without proxy magic. :) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Grok 1.1 doesn't send error messages to terminal?
On 07/08/2010 03:36 PM, Martijn Faassen wrote: > Hi there, > > It appears that Grok 1.1 doesn't send error messages to the terminal by > default? This is really inconvenient and I wonder what change broke it. Argh, wrong mailing list, sorry. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Grok 1.1 doesn't send error messages to terminal?
Hi there, It appears that Grok 1.1 doesn't send error messages to the terminal by default? This is really inconvenient and I wonder what change broke it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildout 1.5 sometime ever please?
Hi there, I was told to ask this question on distutils-devel, which I recall is the proper list for buildout related discussions. See you there. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildout 1.5 sometime ever please?
Hi there, I've been waiting for years for a release of buildout that contains proper isolation from Python's site-packages. The non-isolation is a major flaw in buildout that makes it SO much harder to write proper installation instructions for software such as Grok. We need to wrap Grok's buildout installation using virtualenv --no-site-packages. I just discovered that this installation actually fails if I use an ubuntu-installed virtualenv (or setuptools)! It works with a manually installed version of either, and I'm sure the problem is somewhere in z3c.autoinclude too, but it's still an issue. Last year in september I hacked up some code that would do the isolation. I was then informed that Gary was working on a branch instead, and indeed the branch I saw then looked much improved in features. So I waited. I saw new versions of the branch come and go and I'm not sure what's going on, but I waited. I noticed that in april there was a beta release of buildout that featured such improvements. This release was then withdrawn and overridden with 1.50b2 with the message: "This is a re-release of 1.4.3 to hide the brown-bag release of 1.5.0b1. The changes in 1.5.0b1 will reappear as 1.5.0 soon, when the additional reported problems have been addressed." It is now july, so I'm starting to get my doubts about the word "soon". Have the reported problems been addressed? Is there any hope I can get a buildout that actually provides proper isolation sometime? Can I help? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Toolkit - 1.0a1 release
On 07/06/2010 05:00 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fred Drake wrote: >> On Wed, Jun 30, 2010 at 3:47 PM, Hanno Schlichting wrote: >>> On behalf of the Zope Toolkit release team and the Zope community, I'm >>> happy to announce the first 1.0 alpha release of the Zope Toolkit. >> >> I've yet to hear any response to my post about non-backward-compatible >> classes: >> >> https://mail.zope.org/pipermail/zope-dev/2010-July/040898.html >> >> Is no one else concerned about the backward incompatibility introduced >> by zope.pluggableauth.plugins.session.SessionCredentialsPlugin? > > Given that ZODB3 and zope.app.container are still non-optional > dependencies of the package, I can't see any reason not to restore those > base classes. zope.pluggableauth doesn't seem to depend on zope.app.container? Or did you mean zope.container? I think you meant the latter. I have no objection to adding these back in (zope.container.contained.Contained, that is), as it doesn't change the dependency. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 2.7 and the ZTK - three test failures
On 07/06/2010 01:27 PM, Charlie Clark wrote: > Am 06.07.2010, 13:12 Uhr, schrieb Martijn Faassen: > >> What do you mean, a doctest embedded within another? I'm probably >> missing something. > > No, it's probably me getting the explicit doctest call wrong. It looks to > my novice eyes like print statement is being passed to a "doctest" method. > In matters like these it's usually safe to assume I'm wrong! :-) No, that comment (if you mean that?) is just a way to send configuration parameters to the doctest engine. It calls the view. > hm, I don't think that can be argued with really, particularly given the > amount of time I've actually studied this and other documents over reading > the code. But I do think that, whether the module runs as specified, and > whether the documentation is up to snuff, are of a different nature and, > consequently, so are their failures. Shouldn't we be testing documentation > differently? I think a failure in documentation should ideally show up when running the tests. I do agree that documentation and tests have different concerns and that mixing them can (but does not necessarily have to) lead to poor documentation. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 2.7 and the ZTK - three test failures
Hey, On 07/06/2010 01:04 PM, Charlie Clark wrote: > In the specific zope.formlib test we have a doctest > embedded within another: > > >>> MyForm(None, request)() # doctest: +NORMALIZE_WHITESPACE +ELLIPSIS > There were errors: > (u'Invalid floating point data', >) What do you mean, a doctest embedded within another? I'm probably missing something. > Furthermore, while it's great that form.txt actually runs I wasn't aware > that it contained any additional tests that are not already run and I've > always treated it as testable documentation not as an integral part of the > formlib tests. But I'm ready to be believe this is a large misconception > on my part. I follow the principle that all testable stuff should actually be run during the tests - just in case. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 2.7 and the ZTK - three test failures
On 07/06/2010 09:46 AM, Wichert Akkerman wrote: > On 2010-7-5 23:08, Hanno Schlichting wrote: >> Hi there, >> >> with Python 2.7 final being released, I ran the ZTK tests against it. >> >> zope.exceptions, zope.formlib and zope.proxy all have one test output >> related failure. > > We seem to have a lot of problems with doctests breaking due to changes > in exception formatting. Perhaps a policy to check exceptions using a > try/except or self.assertRaises instead of relying on exact formatting > would be useful? I wish the Python developers saw the exception messages as a core part of their interface, but I guess they won't. While I acknowledge its fragility, I do like the way doctests express exceptions quite a lot, so I'd prefer something that kept them like that. We've used normalization in the past, so if core Python exception messages changed I'd imagine more normalization could help again? Anyway, since we've only had a few test failures the problems with changing message formatting seems to be limited, right? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope summit topics
On 07/05/2010 09:32 PM, Jim Fulton wrote: > On Mon, Jul 5, 2010 at 2:56 PM, Sidnei da Silva > wrote: >> On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen >> wrote: >>> (But hurry.resource is not perfect; I think it'd be better to step out >>> of Python land and create a Javascript packaging system somewhat modeled >>> on Python's, with easy integration into Python projects. A sprint task?) >> >> YUI 3's loader comes to mind (as its the one I have most experience with). > > Ditto for dojo. :) All javascript libraries grow their own packaging systems... I'd be nice if they were all compatible with a more neutral version. Some consolidation would be nice, plus bridging all of that to the Python packaging world. I'd envision a JSON-based metadata system that include intra and inter package dependencies between resources, a way to wrap these packages, a package host along the lines of PyPI, and integration with the Python packaging system. And then wrap all these javascript libraries up and upload them to the package index. The wrapping up can be fairly straightforward (YUI contains a dependency graph), or need analysis. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope summit topics
On 07/05/2010 08:56 PM, Sidnei da Silva wrote: > On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassen > wrote: >> (But hurry.resource is not perfect; I think it'd be better to step out >> of Python land and create a Javascript packaging system somewhat modeled >> on Python's, with easy integration into Python projects. A sprint task?) > > YUI 3's loader comes to mind (as its the one I have most experience with). I've used YUI 2's loader (and hurry.resource was inspired by it). I don't know YUI 3's loader so I should take a look at it. (It strikes me that whatever its technical merits, a javascript packaging system will have to appear neutral politically and YUI's loader won't do that. The YUI 3 loader is connected to the YUI global object?) Anyway, YUI's loader only solves part of the problem - at least the YUI 2 loader doesn't feature a packaging system, just a loading system. I want the ease of saying: "my project depends on YUI version blah" and having YUI version blah being there, just like I can do for a Python package. Such a package should include a dependency map of the included resources as well, not just the code. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope summit topics
Hi there,
Thanks for kicking off this discussion, here's my "old grump" response. :)
On 06/29/2010 05:24 PM, Hanno Schlichting wrote:
> - Agree on a process for larger feature changes in "Zope". Things like
> zope.publisher vs. WSGI, changes to zope.interface semantics, security
> without proxies, the NoZCML movement, ... - we need to have a way to
> talk about these in a structured way, document things, create
> opportunities for feedback from various stakeholders and get a
> definitive answer on whether we allow it or not. There's different
> options for how exactly such a process might look like, but I think we
> definitely need one.
A way to support more drastic innovations in Zope?
It's hard to make decisions when there's no code yet, and it's hard to
start writing code when there's nobody to make a decision that might
ever lead to such a change.
I just know what I've been working on:
* a new publisher
* iface to replace zope.interface and zope.component
I think deciding upon such directions as a community can only be done in
a very broad sense ("we want to replace the publisher"); as soon as you
get into details you might get a few useful ideas and then a lot of
bikeshedding (or nobody talking). Whether such changes will ever make it
will depend on a small group of people doing the initial work and then
doing some marketing.
I've been going around the Zope project for years now to get anything
innovative done; the community in zope-dev only seems to support
maintenance work that everybody can more or less agree on (and we have
trouble even with that). I think in a large measure this is all right:
the Zope project shouldn't radically change at every whim of a
developer. It should however support a community in which developers can
experiment with more radical improvements and then adopt them back
again. We should support innovation better, and have a way to
consolidate innovations back into the ZTK.
Candidates include:
* the work surrounding zope.sqlalchemy and z3c.saconfig; both already
represent consolidations of earlier SA integration work.
* Chameleon replacing zope.pagetemplate, and deprecating zope.pagetemplate?
* javascript resource handling: we have zc.resourcelibrary, and
hurry.resource (radically improving the former), and z3c.hashedresource.
Most web frameworks aren't even aware that they need such features yet,
but we've had them for a while. megrok.resource integrates them all in a
usable way for Grok, but we could adopt this more widely.
(But hurry.resource is not perfect; I think it'd be better to step out
of Python land and create a Javascript packaging system somewhat modeled
on Python's, with easy integration into Python projects. A sprint task?)
> - Try to find a way how we can communicate cool new things we do in
> the various projects.
Good point.
We used to have such ways:
Conference presentations and dedicated Zope sprints. Let's have a few
more of those? And putting more life into planet.zope.org would
certainly help too.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot for ZTK released packages (linux 32)
Tres Seaver wrote: > I don't know yet -- I planned to look at the failure more closely, and > figure out something that would work with the newer mechanize. Just for your information, what we're doing is using wsgi_intercept, which hooks into zope.testbrowser, which uses mechanize. But I think we actually need more tests for it in zope.app.wsgi. Anyway, let me know if you need any help on this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot for ZTK released packages (linux 32)
Tres Seaver wrote: >> python 2.5 and 2.6 : >> - zope.app.wsgi > > I plan to work on fixing this failure, which is due to moving the > zope.testbrowser pin from 3.8.2 to 3,9.1. How are you going to fix it? I'm asking because we depend on zope.app.wsgi for the browser testing of Grok now, at least on a branch. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK release team - kickoff meeting - delayed summary
Hanno Schlichting wrote: > - Look at Tres's list of packages in all three frameworks, decide on a way to > drop things from the initial ZTK set and on a process for the future. As long as things are not dropped immediately. Even though Grok 1.2 might not need foo.bar, transition support might mean it requires it still for those people who are porting over existing projects. Note also that Tres' list is not exactly accurate as it comes to Grok, as Tres assumed that information about deprecation in Grok's setup.py was actually correct. :). Please be careful with that. I think Grok's upcoming 1.2 list will be better. > - Look at and update > http://docs.zope.org/zopetoolkit/about/coreextra.html for > adding/removing policies, probably have a deprecated.cfg file A deprecated.cfg would be a way to support this. Most of zopeapp.cfg could eventually go into deprecated.cfg. The tricky question is what to do those things in zopeapp.cfg which won't be deprecated any time soon. An example is zope.app.wsgi. Should it stay in zopeapp.cfg? we could rename it to zope.wsgi and move it into the ztk.cfg too. You can then argue that since Zope 2 doesn't use it, it shouldn't be in the ZTK, but there are already packages in the ZTK that aren't used by Zope 2. If we moved the four to six things out of zopeapp.cfg over into ztk.cfg (and deprecated the rest) might that be an acceptable extra burden for those who don't use these packages? Eventually of course we'd even want to dump deprecated stuff completely so that we don't need to maintain it at all anymore. We can even move that code into a subdir in SVN and put markers in pypi. You'd need a clear procedure for that too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Update to ZODB3 = 3.9.5 and include a pin for the new package providing the mkzeoinst script
Tres Seaver wrote: > BlueBream or grokproject, which generate code to set up applications, > might want to pull it in (or emit the depenency into the generated > code). Zope2 definitely needs it. If it's sensible for all three projects to use it I think it makes sense for it to be in the ZTK. Even if not all three projects are using it yet. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Update to ZODB3 = 3.9.5 and include a pin for the new package providing the mkzeoinst script
Tres Seaver wrote: > Vincent Fretin wrote: >> If I followed the commits correctly, the mkzeoinst was extracted from >> ZODB3 package and is now in the zope.mkzeoinstance, right? > > Yes. I was questioning why a ZTK user, rather than somebody using an > appserver like Zope2, etc., would need a bin/mkzeoinst script (the only > thing provided by the egg, which I extracted from ZODB at Jim's request). > > ZODB is only included in the ZTK as a dependency, because some packages > import it: nothing else in the ZTK configures server instances. Nothing in zopeapp uses it either? If nothing depends on it, it's less important to track it carefully. Of course if app servers start using it they should be tracking it, and if common infrastructure emerges that builds on it, it might make sense to push it into something more common. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adding the weekly irc meetings record to the ZTK docs?
Charlie Clark wrote: > I think some kind of paper trail is definitely a good idea. Not sure if > docs is the right place but Christian is planning to put the reports into > the svn repository. And both location and form are less important than > having an archive*. We'll have something sorted by next week. Probably. Cool! I think since Sphinx + SVN has been working pretty well for us, it makes sense to do more of that. Creates easy access through a website. But separating it from the ZTK procedural docs might make sense, I don't know exactly how the scopes relate. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] adding the weekly irc meetings record to the ZTK docs?
Hi there, Wouldn't it be useful to add the reports of the weekly IRC meetings to the ZTK docs? This way we have an archive that includes some decisions and such that's easier to go through than the mailing list archive. It also provides a source of information that could then later be integrated into the documentation proper. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 10 OK, 4 Failed, 2 Unknown
Hanno Schlichting wrote: > Dropping Python 2.4 supports makes most sense to me at this stage. > Zope2/Plone only support Python 2.6 for any modern version. > > I don't know what BlueBream and Grok want to support, but would guess > they aim for Python 2.5 + 2.6 support. 2.4 is really old by now. Grok 1.1 aims for 2.5 and 2.6. Grok 1.0 goes for 2.4 and 2.5, but Grok 1.0's stable so we don't have problems when the ZTK is updated. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 10 OK, 4 Failed, 2 Unknown
Hi there, Christophe Combelles wrote: > Unless I missed something, the ZTK was globally compatible with Python2.4 > recently, wasn't it? Do we want the latest changes and Lennart's work to be > part of the ZTK 1.0? For a while already people have been making changes that at least break tests on 2.4. For instance, zope.testing has some facility to pretty print a dictionary that sorts the keys, because Python 2.4's built-in pretty print module apparently doesn't do that yet, meaning random test failures can happen. But people have been updating code to use Python's built-in pretty print facility and this will only be reliable on Python 2.5 and higher. In my opinion it's time to drop Python 2.4 support anyway, but it's been going a bit haphazardly by way of bit rot.. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hi again, One more suggestion I can make is a way to get an integrated changelog for lists of packages such as the ZTK. Right now it's hard to track what kind of changes there have been in the ZTK as a whole; you have to go through all packages. If there were a way to generate a unified changelog between two versions of a ztk.cfg (or other such files), that would be useful in doing releases. A long time ago I experimented with a way to turn a CHANGES.txt into an atom feed and then to aggregate those feeds into a "Planet" in order to get some idea of what's going on. Maybe that'd be an interesting approach to this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hey, Christophe Combelles wrote: > Thanks for these suggestions. This is *exactly* what we (the ztk > release team) need. How wonderfully diplomatic and constructive, my compliments! The release team (you, Hanno and JW) look good to me. >> * please let these guidelines not block most updates by most people >> most of the time; it should be easy to update the ZTK. Gatekeepers >> tend to slow things down a lot, and we don't have them for most >> Python code. > > We have already started discussing about this. One idea is to let the > ZTK update or even release by itself, with the help of the buildbot > infrastructure. I would like to replace the expected ztk bureaucracy > with automated scripts that enforce some rules and *help* people. > Particularly the implicit rules that make people upset when they are > not respected. One example is the first message of the previous > thread ;) > The Zope ecosystem and its processes has become quite complex, and we > cannot expect people to never do errors or to know or read > everything. Yes. But I don't think you can replace people's judgment with processes completely. Differences of judgment will continue to exist too, and they shouldn't lead to deadlocks. In that case it becomes useful to have leadership with vision with the authority to break deadlocks. Vision is also useful to go beyond processes. I think one interesting distinction has to do with structure versus versions. I think we should be quite open in allowing people to release new versions of packages and update the ZTK. Especially bugfix releases, of course, but I think many feature releases can also be safely integrated. Structural changes, where packages are dropped or added, need more discussion. I think the cost for having a package in the ZTK is fairly low as long as it doesn't have a lot of things depending on it, but I realize that the cost is non-zero so shrinking the ZTK sounds like a good plan. Dropping is dangerous for other reasons than adding. Adding a package is dangerous as you give a certain commitment to maintain this package for a long time. Dropping a package is dangerous as you break this commitment. We have the complexity here that we have a *new* project that is actually the underpinning of several projects (Grok, BlueBream, Zope 2) with a long history. I therefore think the issue of dropping is immediately relevant, not only after the 1.0 release. Why is dropping a package an issue? It's an issue because you break backward compatibility promises. Another way to look at it is that you're removing features from the ZTK. Another way to look at it is that you're removing *tests* from the ZTK. We don't expect people to just remove a bunch of tests from zope.component without a very good reason and probably some discussion. I think this is why version updates are generally okay, even drastic version updates, and structural updates are more risky. Of course there are some cases where a version update can break a lot of other packages. I.e. the package is depended on a lot by other packages and you're changing a contract. This is a situation that should be as carefully considered as removing a package. I think the structural organization should follow the lines of interest of project groups more than it should follow lines of content. But I'm wary about trying to organize too much, as separating bits *does* make maintenance harder. >> * there's a 'checknew.py' script to see whether there are releases >> newer than the ZTK. I'd be useful if this were integrated in the >> standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd >> also be nice if that were reusable by other toolkit projects. > > It's on the way. It will probably take the buildout.cfg as an > argument, to allow checking different buildout files with possibly > different versions. Cool. Also reasonable to make 'buildout.cfg' the default, I think? >> * In general it'd be useful if the release team recorded decisions >> in the ZTK documentation. It's confusing to have to go look for >> them in mailing list archives and people tend to forget or >> reinterpret decisions as time goes by. > > Ok, we will write down decisions or status somewhere. We are just > starting organizing ourselves. I think you can just use this: http://docs.zope.org/zopetoolkit/ That's what it is for. It's a Sphinx site. Just a few updates that Wichert can point me to when I get confused would probably help both me and Wichert tremendously. :) I kept decisions here, though they should be reorganized: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html You could probably start a new page like that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zo
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting wrote: > On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen > wrote: >> Last december Hanno made progress on the ZTK's dependency structure, >> removing a lot of dependencies on packages. In his enthusiasm, he >> unilaterally just removed all those suddenly-unneeded (by him!) packages >> from the ZTK, without discussion. > > My actions last December had an unfortunate effect. I assumed a common > understanding of what the ZTK should be and tried to work towards > that, but it turned out that understanding wasn't shared after all. I > should have known better and discussed things before taking any > actions. For not discussing things properly I apologize. Okay, apology accepted, but we already discussed this anyway privately back in december. I apologized for the revert instead of working out the better plan that I came up with a few hours later. In my defense, I was thinking on my feet and we were still touching zope app packages that needed to be testable, so I didn't want the situation where testing this was not possible with the ZTK to linger. I also thought that I was supposed to maintain the process we had in place for removing packages and this was a bold violation of it, compounded by people arguing *I* had the burden of proof after this fait accomplit. I wish there were more steering group members involved at the time, but I couldn't really help that. > In didn't see > any chance of making any progress during the heated debate following > those events, so I decided to let things cool off and let everyone > work on their own for a while. We were making progress in that debate, and actually pretty rapidly, though it was hard to do amongst all the heat. To me, your walking out raised the immediate heat level (though I tried to ignore it), and made it completely impossible for me to cool off, as this signaled an end to collaboration and a lack of trust in me. I tried to cool off for 4 months, but today I still found myself upset about it, so that obviously wasn't working very well. >> No, I cannot present it less acrimoniously. The lack of commitment and >> trust displayed back then still hurts me too much for that. > > Martijn and me tried to discuss this off-list. I think at this stage > there's no way to solve our disagreement. I'd rather not continue any > of this in public, as I don't see how this would have any constructive > effect. I don't know, perhaps you'll get me more engaged again. I'm in the situation that I have to work with people here, I want to work with people here, but my trust in my ability to work with people here was seriously damaged. Maybe that gets me out of my dilemma. > The Zope community asked Christophe, Jan-Wijbrand and me to act as a > release team for the ZTK and we started working on this task. > I intend to continue to work in this group. If the Zope community feels I'm > not > qualified for the job or the other two team members don't want to work > with me, I'll happily step down. I think you're qualified for the job and I trust you'll do a good one. I just hope you'll get more trust and credit than I got in december. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Lennart Regebro wrote: > On Mon, May 3, 2010 at 20:13, Martijn Faassen wrote: >> Since there are no ZTK releases Grok and BlueBream gain stability by >> pinning to a particular revision of ztk.cfg (and moving it forward when >> needed). Zope 2 could easily do the same. If more is needed, then a >> branch or tag can easily be made. Besides the perennial documentation >> issues, I also don't see why we couldn't just start releasing the ZTK; >> instead of pinning to an SVN revision we'd start pinning to an SVN tag >> (or a release URL with version number in it). What's the holdup, really? > > Making a ZTK 1.0a seems to be a good idea to me, and should help here. > And we don't have to commit to anything, since it's an alpha. I think the list needs to commit to something, because we do have people coming from older versions of Grok, BlueBream (in the form of Zope 3) and Zope 2 (though apparently Zope 2 has the least issues). While the ZTK might be new the underlying codebase isn't new at all. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Charlie Clark wrote: > FWIW this is a very poor > strategy to win people over to your point of view. I'm not trying to win over people to my point of view. I tried that last year, but people just forked when they couldn't work it out with me. I've learned that rash actions without consideration is the favorite method to accomplish things, so I'm trying me some of that to see whether that works better. > You have not succeeded in making me aware of: 1) the issue and 2) a > possible solution. The ZTK consists of a list that says which packages work together. So it's a list like: zope.component = 3.4 zope.interface = 3.7 zope.container = 3.10 The ZTK also has test infrastructure. So when (or even before) you release zope.container 3.11, you can easily run all the tests of all the packages in the ZTK and see whether anything breaks with your changes. The list of ZTK packages is used (at least subsets of this list) by Grok, BlueBream and, until december, Zope 2. Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. The version information was just gone. I wasn't happy that, both in my capacity as a Grok developer and in my capacity of someone honestly trying to balance the interests of parties using the ZTK. I knew those packages needed to be tested at least for Grok for a while longer. (and BlueBream too, but that didn't exist yet. We had a Zope 3 in limbo then). So I objected to this sudden removal, and went and restored the information that Hanno removed until we could discuss the right course of action. This reversion greatly upset the Zope 2 developers and they decided, an hour later, to fork the ZTK and maintain their own list of versions. We were in the middle of a discussion that was about a lot of stuff, but also included constructive attempts by me to try to resolve the situation so we could continue to work together. There was no real reason to do so - Zope 2 could've continued to use the longer version list just fine without technical problems (Grok does the same right now). But as soon as the unneeded packages weren't needed anymore by Zope 2, they wanted to stop caring about them at that very moment. I drew the consequences and a while later stepped down as ZTK steering group member. We've been in this situation ever since. It wouldn't have bothered me so much, except that people make releases. So, Zope 2 people release packages that are also in the ZTK and update their own version list and not the ZTK. They don't run the ZTK tests against their new releases. They leave it up to the ZTK maintainers to do those updates and run the ZTK's tests. This is rather annoying. The lists are needlessly out of sync. > Additionally to suggest that there has been no progress > in this area over the last couple of months seems contrary to the facts. > You have obviously a big, and possibly very justified, itch to scratch. Is > it possible to present it less acrimoniously? If you succeed in > monopolising the conversation we will be back where started. No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hey,
Tres Seaver wrote:
[snip]
> I expect to see Zope2 trunk move to using the ZTK versions list quite
> soon: more than that, I'm willing to to the work to see that it happens
> (verifying that everything passes / works with the change), and give
> Hanno the patch to make it so, assuming he doesn't get around to it.
Cool. That's good to hear and something I really need to hear. :) I
think you'll mostly be giving the ztk.cfg a patch to make it so, as Zope
2's list is ahead with a lot of mostly bugfix versions.
>> I haven't seen a plausible reason why the fork should be necessary. It
>> just uses some updated versions of packages (mostly bugfix releases)
>> that would have been updated in the ZTK as well if people had bothered
>> to update them.
>
> If the release manager group gets consensus quickly on how their
> projects' interests align in the ZTK, then the fork can go away. Until
> then, pushing changes into the ZTK without consulting those projects'
> needs is premature.
Yes, such a change without such consultation was what created the
problem in december. But that was a structural change of definition --
what is *in* the ZTK, not one of which releases were in the ZTK. It had
something to do with letting the last zope.app.* dependency go from the
cluster of zope.* packages.
I'll note a short version list is not needed in order to feel that
you're shrinking dependencies. I've been using depgraph for that. I will
admit though that the longer the version list that is tested, the slower
the tests and buildout run, of course, so that may be a concern for some
(but how heavy should it weigh?). Could be something for the release
managers to flesh out the balance between things.
We haven't had the opportunity to have conflicts about specific releases
yet ("I want zope.interface 4.3!" "no! 4.5!"). I think it's not a very
big issue until someone starts doing a big dependency refactoring again
- but that again is a structural issue, not a version issue.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hi there, Tres Seaver wrote: > One issue with insta-updates to ztk.cfg is that ongoing development of a > package can be in real tension with the needs of ZTK consumers for > "stability" in the package set. Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? > E.g., I have updated > zope.testbrowser/trunk to use the new version of mechanize, but don't > know whether pulling that version into the ZTK proper is reasonable (in > fact, I decided to have the ZTK development buildout use a "stable" > branch for the meanwhile). Why wouldn't it be reasonable to try at least? If you tested it with the ZTK, you might find issues with your integration of a new version of mechanize. But anyway, you didn't release zope.testbrowser either yet, so this isn't a very good example of what I'm complaining about. I understand that you sometimes want to be careful about what to include, but this kind of "ZTK-breaking" release is very rare and I haven't seen a good example of it in Zope 2's list. Is there? > If you are a ZTK consumer, and would like to see the ZTK include a newer > version of one of its packages, then that need has to be balanced with > the needs of the "downstream" projects. In effect, the new "release > manager group" is supposed to represent the interests of Grok, Zope2, > and BlueBream in a shared definition of the ZTK "known good set." > Getting that nailed down into a version which works for all three is > *way* more important than picking up individual package changes. I'll note that Zope 2's fork is moving *faster* than the ZTK itself right now; a whole slew of mostly bugfix versions are used by Zope 2's list that aren't in the ZTK. I don't see a reason why instead the ZTK couldn't have been updated with those bugfix releases and Zope 2 could've used that. That way Grok and BlueBream would have benefited from the same fixes. And if Zope 2 needs to do a bigger change of a package that's in the ZTK, that might break other users of the ZTK, and do a release without discussing it here, then there is something wrong already. Anyway, this all has nothing to do with why the fork happened in december. The fork happened in december because of a very specific debate that has nothing to do with this. Such lack of commitment made me less interested in committing my own time and energy as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro wrote: > On Mon, May 3, 2010 at 18:09, Martijn Faassen wrote: >> Hanno is making releases of packages in the ZTK. So it's not just >> Hanno's waste of time; it's mine too. > > Obviously he shouldn't hurt the main ZTK in any way. That would be a > problem (even if i missed this incident completely and hence dn't > understand what or how things broke). But I think the fork in itself > is a red herring. I spent months trying to get everybody together and there was a fork because we had a disagreement in december. Instead of working together and working with me, people just forked. That really hurt. With that lack of commitment to the ZTK, I didn't feel inclined to be committed to it either. I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro wrote: > I don't know anything about the fork, but my view of the fork is that > of Hanno wants a fork, Hanno can have a fork, as long as he doesn't > try to poke anyones eye out with it. If it's a stupid waste of time, > it's Hannos stupid waste of time. Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. That's where I was coming from when this discussion started. It didn't help that the action of making the fork really hurt me at the time - I'm not inclined to be calm about it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Lennart Regebro wrote: > On Mon, May 3, 2010 at 15:41, Martijn Faassen wrote: >> Well, I'm disappointed in the zope documentation process then. Work faster! > > :) > >> If you don't inform people about this release manager team thingy, you >> can't rightly expect people like me to care about it. > > Heh. Martijn, I understand you are just shaking off all the shit that > you had to take, but I'm not sure everyone gets the joke. That's because it's not a joke. It's because I'm pissed off. Answers like "read the mailing list archives" and "we're working on it" are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Alex Clark wrote: > On 2010-05-03, Wichert Akkerman wrote: >> On 5/3/10 15:41 , Martijn Faassen wrote: >>> Lennart Regebro wrote: >>>> On Mon, May 3, 2010 at 13:22, Martijn Faassen >>>> wrote: >>>>> Wichert Akkerman wrote: >> If we're going to make cheap shots: that's still a lot faster than the >> grok release cycle. > > Guys, please, this is like watching your parents fight ;-) Can't we all just > get along? :-) I can't. I think I've contributed a lot to this community, I've tried to be fair and work out differences and make compromises. It wasn't easy. You'd think it'd get you some respect and trust. Then, when it came down to it, instead of respect, trust and a willingness to cooperate (and yes, I think I've tried to do all of that myself; I don't think I'm a hypocrite on this), I got a fork. Thanks guys. So I stepped down, as obviously people weren't willing to work with me. I tried to stay out of zope-dev for the last 4 months, as it just gets on my nerves now. But the fork continues. I see it in the checkins messages. It's causing me extra things to worry about - the new releases don't get tested with all the libraries in the ZTK, and I use other libraries in the ZTK. It's just so stupid, too. So unnecessary and counterproductive. But like it or not (I don't really like it much right now, to be honest), I still a user of the ZTK. I contribute to it. So I think that means I get to make suggestions and complain when I want to. That's how it works in an open source project. The leadership, whoever they are, will just have to deal with it. But forgive me when I don't feel particularly inclined to spare anyone's feelings. Even when I was trying to do that, I think I stepped on enough toes anyway, so why bother? > As someone looking in from the outside (Plone), and hoping > to become more active in the Zope community in the future, I > wonder what it's going to take to restore some harmony and > direction in here? It seems like I've been reading various > flames for months now. I don't know. It'd help if people tried to work with each other instead and give each other a bit of credit, instead of fork or do whatever Wichert did in this thread (yeah, I know I'm in this thread too and doing the wrong stuff too. But Wichert, you're just not being constructive at all here, sorry). But I tried that and it didn't really work, so I am trying something else. That is, I think it *did* work (the ZTK is there, it's made a lot of progress), but it didn't work for *me*. > To put things in perspective, for folks in here who may be "too close to it", > the Zope ecosystem is *really* starting to shape up IMO (i.e. leaving the > Zope 3 confusion in the past, etc.). I think I understand it now (after years > of study), and can actually explain it to others! So let's try to keep up the > *great* work and let the "little things" slide… It's not been a little thing to me, sorry. It felt like a big thing that didn't slide off but steamrollered over me. I now have four months distance from it and I'm still wounded by it. Sure, there are a lot of good things going on. I think it's great what BlueBream is up to. And Hanno's doing all kinds of good work; I'm happy to acknowledge that. And last week we finally decoupled Grok from most of the zope.app.* packages. I'm pretty happy about that, too. But as a group we aren't very good at treating people who attempt to lead for the good of the group. And seriously, you can't replace leadership with bureaucracy and do as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hanno Schlichting wrote: > Hi Martijn, > > On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen > wrote: >> Because my suggestions (besides the fork issue) as a ZTK >> user/contributor were scattered through the thread, here's a handy summary: > > Thank you very much for your suggestions. I'm sure the release team > will pick these up, once we get to start actual discussions. > > We have only started talking to each other last week and are slowly > bootstrapping. Please don't expect us to solve everything in a matter > of days. Why not? Why can't you solve things in a matter of days? The fork took 5 minutes. Does it really take more than saying, "okay, we're going to unfork", a few modifications to a buildout.cfg and figuring out a couple of test failures? I know it's hard to admit a mistake, but heck, it shouldn't have to take 4 months. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Lennart Regebro wrote: > On Mon, May 3, 2010 at 13:22, Martijn Faassen wrote: >> Wichert Akkerman wrote: >>> Sorry, my mistake. I meant the ZTK release manage group, not the now >>> defunct ZTK steering group, > > Well, if it's defunct or not is up to the members of the steering > group. The steering group created itself, and may disband itself if it > so wishes. It has all the right in the world to continue existing, > even if the idea is that the ZTK oversight will be done by the release > manager team instead. > >> If it's defunct someone better update the documentation. > > The creation of the release manager team was only recently concluded. Two weeks ago. Process started a month ago. > To expect zope process documentation to update quickly is unrealistic. Well, I'm disappointed in the zope documentation process then. Work faster! If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] summary of suggestions
Hi there, Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: * please construct guidelines for updating the ZTK when making a release of a package that's managed by the ZTK project. It's useful people test their changes within the ZTK. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. * (new idea) similarly it'd be nice if there were a script integrated that could check which binary egg releases exist for Windows (32 bit, 64 bit, Python version). Right now BlueBream is maintaining a list here: http://wiki.zope.org/bluebream/StatusOfWindowsBinaryPackages * Please update the ZTK documentation about the status of the ZTK steering group and the ZTK release team. It's unclear to newcomers such as myself. * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Wichert Akkerman wrote: > Sorry, my mistake. I meant the ZTK release manage group, not the now > defunct ZTK steering group, If it's defunct someone better update the documentation. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Wichert Akkerman wrote: > On 5/3/10 12:52 , Martijn Faassen wrote: >> Wichert Akkerman wrote: >>> I suggest that we wait impatiently for the ZTK steering committee to >>> come up with a useful policy instead of trying to do their work when >>> none of us volunteered for the task. >> I don't understand your suggestion. Could you rephrase it? >> >> I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm >> actually offering constructive suggestions. Are you? > > A ZTK steering group was created to help define and manage the ZTK. You > did not volunteer for that, and neither did I. Hanno did, so why not let > him do his job instead of distracting him by rehashing a discussion that > already happened on this list. I'm a ZTK user. I thought this was the mailing list for ZTK users to bring up issues they have? Am I to understand that this open source project works in such a way that we can't even say anything until the steering group is done coming up with guidelines? How *do* I ask the steering group for things? Are suggestions really off the table? I think you should explain things better to newcomers such as me. :) Last year you weren't so overly protective of the ZTK steering group. What's more, you sound like you think the ZTK steering group formed this year! Wow. You seem to have forgotten 2009 already? I'd be mightily pissed off that you're ignoring my hard work last year if it weren't so hilariously silly. :) Maybe you're worried I'm trying to take over. I'm not, I'm just a user and contributor to this project. Anyway, I didn't realize the steering group got disbanded and reformed; the Zope Toolkit documentation still seems to refer to the old steering group: http://docs.zope.org/zopetoolkit/steeringgroup/members.html Someone should update it. That way people don't have to go through the mailing list archives to find decisions. This was something that the 2009 incarnation of the steering group was trying to do and I think the 2010 version would do well to emulate that, while of course trying to improve on the things that didn't work so well last year. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Wichert Akkerman wrote: > On 5/3/10 12:51 , Martijn Faassen wrote: >> Wichert Akkerman wrote: >>> Can we please not rehash an old discussion or make this personal? This >>> has all been discussed too often already. >> As far as I know, I've *never* discussed this fork on this list, but I >> might be wrong; feel free to dig the archives. But that doesn't matter: >> the fork is still there. So: wtf, Wichert? > > Perhaps you haven't, but others have discussed the reason the fork was > cerated and why it still exists. Since then many things have happened > including the creation of the ZTK steering group, of which Hanno is a > member. The ZTK steering group was created about a year ago, so I'm not sure what you're trying to suggest here. I just hope you're not suggesting I didn't do anything in 2009. By the way: at the time I invited Hanno into the group, but he declined then, and I respect that, but just so you know. I must say it totally baffles me that the ZTK was acceptable to Zope 2 until january, and became unacceptable at that point. All answers are probably in that mailing list thread, but I can't be bothered to look it up. Please just make the fork go away. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Martijn Faassen wrote: [snip] > Why is this in a separate .cfg unlike the other tools that come with the > ZTK? Unless creating this extra script is very expensive, I think it > makes sense to generate it in 'bin' along with the rest of the scripts. To expand on that, it'd be nice if it were also easy to integrate in other toolkits such as the Grok toolkit. I imagine the BlueBream people would also like to have such a thing. The other scripts (such as the cool depgraph stuff that Hanno created) are reusable in that way, and it's been very nice. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Wichert Akkerman wrote: > I suggest that we wait impatiently for the ZTK steering committee to > come up with a useful policy instead of trying to do their work when > none of us volunteered for the task. I don't understand your suggestion. Could you rephrase it? I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Wichert Akkerman wrote: > Can we please not rehash an old discussion or make this personal? This > has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert? There is a fork of the ZTK being maintained today, right now. I want it to stop. Hanno, please stop the fork. I don't know what Hanno is trying to pull by saying he's going to "look into" the ZTK. He helped build the ZTK, and then he forked it, which took all of 5 minutes, and now 4 months down the road he's looking into the ZTK? I think it shouldn't take more than 10 minutes to unfork it. And if someone else is maintaining a fork of the ZTK, I'll be happy to single out that individual too. Feel free to fork the ZTK, Wichert, and I'll be complaining about *you*. If I fork the ZTK you get to complain about me. But you didn't, I didn't, but Hanno did. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, Hanno Schlichting wrote: > I expect us to define the process around package releases and updating > the ZTK. It's not entirely clear to me who should and who is allowed > to update the ZTK definition. We'll figure things out and once we have > I'll stick to the rules. My few cents: I think everybody should be allowed to update the ZTK definition. They should follow certain guidelines (run tests, and such. Maybe updating a changelog is a good idea too). Stability can be taken care of by branching and tagging. I.e. the same guidelines as we have for other pieces of code can be a good starting point. To get back to the discussion that caused the fork. We have implicit, but I think widely understood and accepted, rules about backwards compatibility. So we don't expect someone to rip out half the code of a Python package just like that. Generally we expect the tests to continue to run. Similarly we shouldn't just drop things from the ZTK without special action (this involves removing tests too!). We started to try to spell some of that out here long ago: http://docs.zope.org/zopetoolkit/about/coreextra.html But I'd hate it if the ZTK trunk became some kind of bureaucratic maze, as it'd stop me from getting work done. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hanno Schlichting wrote: > Good evening :) > > If you have a specific issue with me, you might contact me in private. > But with your follow-ups this turned into a more general issue. No, I think this needs to be public as the ZTK is a public project that I care about. And you're not playing your proper part in it. You're not going to listen to me (otherwise the fork would never have happened; you had an issue with listening to me), so I'm informing the rest of the community. Maybe you'll listen to them. The fork is counterproductive. And it's just annoying me. It's time for this annoyance to disappear. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Vincent Fretin wrote: > For the tool, I think I did it already. I modified one of Hanno's > script some times ago: > cd zopetoolkit/trunk > bin/buildout -c checknew.cfg > bin/python checknew.py Cool! This tool should be documented if it isn't already. Why is this in a separate .cfg unlike the other tools that come with the ZTK? Unless creating this extra script is very expensive, I think it makes sense to generate it in 'bin' along with the rest of the scripts. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.exceptiosn release has no relaese date
Lennart Regebro wrote: > I thought it was painless already, but maybe I was wrong. :) It's very nice to be able to do a full release by just typing 'fullrelease' and saying 'yes' a number of times. The tool made a convert out of me, and I know others who also were pleased by how much it sped things up, even though, as I was, they were initially somewhat skeptical. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.exceptiosn release has no relaese date
Hi there, Two typos in the title, maybe I'm turning into Jim. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, Martijn Faassen wrote: > Of course what applies to Hanno should apply to others making releases > of packages maintained by the Zope Toolkit project as well. I think the > ZTK leadership should figure out some kind of guidelines for this that > people can follow. Maybe someone can write a tool too to check up how > far a toolkit is out of sync with the latest releases. Just some ideas. Don't think you're off the hook with me though, Hanno. :) Hanno is special as he's maintaining a fork of the ZTK and was maintaining the ZTK already in the past before he forked it. If I were the ZTK leadership such a thing would probably frustrate me a lot, so it's a good thing I'm not. Instead I can just express my displeasure out loud. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanno, please update the ZTK
Hi there, Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Hanno, please update the ZTK
Hi there, Hanno, can you please update the zopetoolkit and do tests there as well when you make releases of packages maintained by the Zope Toolkit project? Because otherwise you're just wasting my time trying to sync things up again, and that's annoying. Not annoying me is one good reason, but there are other good reasons why you should be updating the ZTK but I'm sure the people in charge of the ZTK can express those. They haven't done so probably because they figured you already knew the reasons. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.exceptiosn release has no relaese date
Hi there, I saw a zope.exceptions release on pypi, but it has no release date is marked in its change log: http://pypi.python.org/pypi/zope.exceptions/3.6.0 I recommend following the procedure to avoid such issues: http://docs.zope.org/zopetoolkit/process/releasing-software.html I highly recommend the use of zest.releaser to make releasing pretty painless. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] pypi access to zope.browserresource, zope.browsermenu
Stephan Richter wrote: > On Monday 26 April 2010, Martijn Faassen wrote: >> Could someone give me and Hanno pypi access to zope.browserresource and >> zope.browsermenu? > > I am in the process to give you access to all the packages that I am an owner > of (now that PyPI is fixed again. :-) > > Let me know if hannosch wants the same. Thanks! Thanks to you doing this in the previous round, I already was the owner already of a huge range of packages, but some of the ones that dropped out of refactorings were missing. I'll let Hanno speak for himself. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] pypi access to zope.browserresource, zope.browsermenu
Hi there, Could someone give me and Hanno pypi access to zope.browserresource and zope.browsermenu? Our pypi usernames are: faassen hannosch Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK community packages
Hi there, Tres Seaver wrote: > Martijn Faassen wrote: > >> Interesting, and thanks for doing this. Concerning Grok, did you look at >> Grok 1.0 or Grok 1.1? > > Just grok/trunk (I was trying to think about the "state of ZTK" in terms > of how it was being used by latest-and-greatest versions of downstream > projects). Okay, that should be approximately 1.1. > and the following further packages say that they are marked as unused, > according to the dependency checker: > > - - zope.app.appsetup This is definitely being used. I figure it's a dependency through ZCML. >> Of course we'll also need the other zope.app.* packages for a while >> longer to provide backward compatibility imports and such for those >> upgrading existing Grok apps. > > I'm assuming that BBB imports could be "soft" dependencies, and that > developers who are upgrading from earlier Grok versions can adjust their > own buildouts or package depenencies to pull the extras in without Grok > needing to provide "convenience dependencies" -- am I right? Yes. We'll likely have a grok-backwards package or something like that that depends on the "lost" dependencies, so a developer can depend on that with their project. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK community packages
Hey, Interesting, and thanks for doing this. Concerning Grok, did you look at Grok 1.0 or Grok 1.1? For Grok 1.2 we've identified that the following zope.app packages are certainly used: * zope.app.wsgi * zope.app.appsetup * zope.app.publication We've eliminated the dependencies of these packages on zope.app.testing and zope.app.zcmlfiles, which both pull in a lot of zope.app.* stuff. We've expanded zope.app.wsgi so we can run functional tests and testbrowser tests without zope.app.testing involved; see zope.app.wsgi.testlayer. We're in the process for Grok 1.2 to try to reduce Grok's dependencies to this subset. The grokcore.* packages already eliminate the zope.app.zcmlfiles and zope.app.testing dependencies (in the proper development branches), but as of yesterday Grok itself only eliminates the zope.app.testing dependency so far - zope.app.zcmlfiles is next. We expect more zope.app.* packages than the ones above will be needed to actually run Grok; we don't quite know which ones yet, and we'll be looking at them on a case by case basis. Of course we'll also need the other zope.app.* packages for a while longer to provide backward compatibility imports and such for those upgrading existing Grok apps. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Hi there, I've said my piece. I'm not going to argue about it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Hi there, > Chris McDonough suggests to ponder further structuring of the ZTK into > separate sub-sets which might allow us to get better mileage regarding > maintenance and release management. He gave the example of the > "Bicycle Toolkit" (zope.component, zope.configuration, > zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. For now, just see the extra packages as the ultimate in compatibility tests and run them please. Furthermore, the bicycle toolkit is the only candidate for such splitting up right now; other groupings don't seem to be well defined. Finally, people who want fine grained already have the ultimate in fine-grained in the form of individual releases. Maybe next year. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] quitting the ZTK steering group
Hi there, This is to announce my withdrawal from the Zope Toolkit steering group. I withdraw from the Zope Toolkit steering group for two reasons: * The steering group is not working as a group. Most steering group members haven't been doing much steering. This left me by myself to try to give direction. I cannot blame the others for committing their time differently, but this isn't the balance of work I signed up for. * Trying to steer the ZTK took a large amount of my energy. The discussions are quite draining and the benefit to me has not been worth the frustration. In the past year we've made large changes to the dependency structure of packages, cleaning it up. We've also improved compat testing and dependency analysis infrastructure a lot. That's the technical part. The community consequences are also important. We've been able to redefine the focus of various projects under the Zope umbrella. Separating the concern of the ZTK from Zope 3 made another refocusing project like BlueBream possible, and made more clear the relation Grok and Zope 2 have with the libraries in the ZTK. I think there is a lot more that can be done, but I don't want to feel responsible for it. Here is my analysis of problems with the ZTK: * Unclear leadership situation. I tried to resolve this by founding the ZTK project and steering group in the first place. Besides the time investment problems mentioned before, this (my?) leadership is also not fully accepted, or its judgment is not fully trusted. * Even though endless discussions take place, communication is frequently poor and frustrating at the same time. Bigger changes take too much energy to discuss. People give up even trying to cooperate and do it alone as it's a way to get things done. This creates a vicious cycle. * The commitment of parties to work together on the ZTK is fragile. Witness Zope 2 withdrawing from the ZTK quickly after some disagreements (with me). My commitment to leading the ZTK as a community project has now disappeared as well. I am primarily interested in the development of Grok. I came to the ZTK to tackle important issues for Grok, and now am going to focus my attention on Grok again. This means that I may contribute to the vicious cycle I mentioned above, but so be it. What this means for the ZTK or the steering group I do not know. The ZTK matters to me as a foundation to Grok. In a wider sense, I believe that a broader base of people using the ZTK is good for the Zope community and Grok as well. I also believe a person or group who offers leadership and has a final say is healthy for the project -- just random interested people voting -1 or +1 or -1000 or +1000 on the mailing list is a recipe for stagnation. We will have to see what the steering group, or anyone else, will come up with. I've tried to ignore zope-dev as much as possible recently, because I don't want to be dragged back into sometimes frustrating discussions. If you want to reach me you can email me or talk on grok-dev. Good luck, everybody. Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Martijn Faassen wrote: [snip] > But I do see that Python 2.4 has a failed test, so we do need to fix that. Some of those failure appears to be because some code was switched over to the Python standard library pprint from the version in zope.testing, and in Python 2.4 that doesn't sort dictionaries. http://dev.thehealthagency.com/buildbot/builders/ztk%20slave-ubuntu32-py2.4/builds/4/steps/test/logs/stdio We already talked about undeprecating that pprint function in zope.testing.doctestunit. It'd be nice if someone looked into doing that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martijn Faassen wrote: >> Hey Tres, >> >> >> Tres Seaver wrote: >> >>> You're kidding, right? >> [snip] >>> My self-interest? Not really: you are appealing to my altruism, in the >>> fact that I care about the *broader* Zope community (broader than Zope2, >>> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >>> rely any longer on any of thsoe pacakages at all, which makes my direct >>> interest in them exactly zero. >> Basically we all worked together for a year. Now Zope 2 happens to be >> done first moving off zope.app, so you're telling me f$%#%Q#k you, I >> don't need you anymore, go away. > > That's not what he is telling you. I don't think he ever intentionally > "worked together" to support zope.app* packages in any way. If anything, > he may have had input into and interest in the "small ZTK" packages > and/or direction, so his viewpoint has never changed. Well, Zope 2 released with a smaller but present dependency on zope.app some time ago. Those zope.app packages were at least until then relevant to Zope 2 developers. If support for them had been dropped by someone then, they would have had to pick up maintaining them themselves, if they wanted to continue tracking the ZTK and give Zope 2 users an upgrade path out of zope.app. Whether they are still relevant today is harder to say as Zope 2 already had some transition time behind it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hermann Himmelbauer wrote: >> Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver: >>> Martijn Faassen wrote: >>>> Obviously I cannot *force* ZTK >>>> maintainers to worry about this. Instead I'm appealing to your >>>> self-interest. And of course the transition burden is shared and should >>>> not fall solely or even predominantly on the ZTK maintainers. >>> My self-interest? Not really: you are appealing to my altruism, in the >>> fact that I care about the *broader* Zope community (broader than Zope2, >>> Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) >>> rely any longer on any of thsoe pacakages at all, which makes my direct >>> interest in them exactly zero. >> If the ZTK is decoupled from other users, e.g. from people who rely on >> zope.app, then they will simply not use it, or do a fork. >> >> This way, ZTK users are lost, which also leads to a loss of supporters and >> developers and results in a shrinking interest in ZTK, whose primary goal >> was/is to be _the_ base for all other Zope-based applications. > > How is that any different from people who won't use the ZTK because they > don't want to deal with any zope.app* baggage? We were all together carrying the old zope.app* baggage for reasons of transitioning out of it. Then one of the party managed to transition out of it first. So without warning, they dropped the baggage and ran away as fast as they could. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Hermann Himmelbauer wrote: > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: >> Hermann Himmelbauer wrote: >>> But I have to further state that I'm locked into Zope 3.4.0 as the >>> support for Python 2.4 was dropped, so I can't upgrade to the current >>> ZTK. >> This is a surprise to me. I thought we still supported Python 2.4 > > That's a surprise to me, too: I remember endless discussions about dropping > support for Python 2.4 on this list, let me see: > > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html > > I thought the outcome was somehow that Python 2.4 support was dropped? I recall the conclusion was not to do that yet. > But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with > Python 2.4 for the ZTK? I think we have a buildbot for it. http://dev.thehealthagency.com/buildbot/waterfall But I do see that Python 2.4 has a failed test, so we do need to fix that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Hi Tres, You don't seem to get what I kept telling you over and over. I'm therefore going to be more blunt. I don't want to use zope.app packages in Grok. Grok wants to get rid of zope.app packages. That's the very idea. We pushed this from the start. I spent a huge amount of time to make this possible, just like everyone else. But Grok isn't there yet. Neither are people who have to maintain Zope 3 apps. But I have to use zope.app packages in Grok 1.1, because people need to have a way to move off zope.app in a working system. It will be the equivalent, I believe, of Zope 2.12, though the details are different. We cannot ask users to switch their imports in Grok 1.0, as there, for instance, zope.app.container is the only thing that exists. There is no zope.container yet to switch your imports to. I am not asking you to help me maintain zope.app packages until the end of time. I'm asking you to help me support backwards compatibility code in zope.app for a while longer, until I and others have transitioned away from those packages as well. If that code goes untested, it breaks. It already started breaking. Jan-Wijbrand noticed test failures on zope.app.exception, just checking it out from svn.zope.org. He didn't know a zope.publisher 3.12 was released that created this breakage. He didn't even pin down the ZTK or anything; it was just a checkout using the most recent releases. The person who makes the change in the original package is likely able to identify the cause for such breakage much more easily, and either warn people about what to do, or make a quick fix himself. So I'm using zope.app packages, and changes happen in the zope.* subset, and zope.app packages are now breaking in SVN when buildouts are run. Until recently Zope 2 used zope.app packages too, for backwards compatibility reasons. If the situation had been reversed and Grok had been off zope.app first, I don't think you would have been very happy if suddenly these started breaking as they became unmaintained. Zope 2 is able to move off it more easily for a variety of reasons. Now that you're done, but we aren't yet, I am hearing a loud "screw you, we're done, we don't care about you anymore" from you. That really pisses me off. It's also just plain stupid if you only a little bit enlightened in your self-interest and want the ZTK to succeed and people outside the Zope 2 community to use it. You're making that a lot harder. You're making my lots life harder for short-term selfish reasons. And it makes me really want to say "screw you too". But that would not be very enlightened. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Hermann Himmelbauer wrote: > But I have to further state that I'm locked into Zope 3.4.0 as the support > for > Python 2.4 was dropped, so I can't upgrade to the current ZTK. This is a surprise to me. I thought we still supported Python 2.4 Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Hey Tres, Tres Seaver wrote: > You're kidding, right? [snip] > My self-interest? Not really: you are appealing to my altruism, in the > fact that I care about the *broader* Zope community (broader than Zope2, > Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) > rely any longer on any of thsoe pacakages at all, which makes my direct > interest in them exactly zero. Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away. Thanks. Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
