On Oct 2, 2007, at 6:03 AM, Roger Ineichen wrote:
Betreff: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
Roger Inechens split of zope.app.securitypolicy into
zope.securitypolicy cause loads of problems, because many of
the deferred imports were incorrect. I saw Stefan Richter
fixed some, and I have fixed some more.
Yes you are right
First somebody that can make releases (which may or may not
include me, I honestly don't know who can make releases of
eggs) needs to make a new one. But we also need to avoid this
stuff in the future.
Yes, we always have to avoid errors, but sometimes it happens.
And since we dont test against the trunk, we don't see this
kind of errors anymore. This means we test against custom
projects. I didn't fully recognize this and was trusting the
tests. But I was wrong. We don't have tests for this anymore.
We probably didn't have test for my error at all.
In other words; Right now we only test if a egg works
within their dependency. But we don't test other eggs
if they work with the egg we develop.
See all my different mails about this topic!
Yes, please do. It's up to people making changes to use some
judgement. I mentioned in that thread that when I make changes to
"core" components, I often do test against the old trunk tree.
Despite all of your complaints about the need to do this, you didn't.
How is the recommended process to solve this? Some sort of
unittest to make sure the deferred impoirt work? Is there an
example of this somewhere?
I'm proposing to test against a set of possible breaking
stuff. This means we need a kind of zope3 trunk egg which
our test will deoend on.
As I mentioned in the thread you want us to pay attention to, this
isn't necessary. In fact, I doubt it would be useful. I think we
need a Zope 3 application buildout that builds the traditional Zope 3
app. You can then introduce a develop egg for the package you are
changing there. In the mean time, all you need is a trunk checkout
and, possibly, to adjust an external. (I don't remember how the
externals are set up there.)
See the mails form Stpehan Richter about that. Jim also
agrees on that but is thinking this should be optional
as far as I understand the mails between Stephan and Jim.
We defently lost the overall tests we had in the trunk setup.
Most people aren't changing these components. Nevertheless, we still
have the old tree available for testing. We didn't lose anything.
And this is a very bad idea. If we don't recommend to run
all tests again form a single egg refactoring, we will
see more errors like this.
Don't you think it's a little hypocritical bemoaning that we're not
doing this when you don't do it yourself?
I personaly think, less test -- more errors.
So test! What's stopping you? The old tree is still available!
If someone wants to make this better, a working Zope 3 application
buildout would help a lot. I doubt it would be that hard to finish
at this point.
Zope3-dev mailing list