AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.

[Jim Fulton]

On Oct 2, 2007, at 6:03 AM, Roger Ineichen wrote:

> Hi Lennart
>
>> 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.

Jim

--
Jim Fulton
Zope Corporation