AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
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! 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. 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. 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. Some of us are thinking about to automate this tests with buildbot. But this tests will only test released packages which is also bad. I think the only way to automate such tests can be supported by a staging server. I personaly think, less test -- more errors. Even if we try hard to avoid errors during development. Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
Hi Jim, Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors. [...] 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. That's not true. I did test the package against the trunk. But the problem was, I also adjusted the imports in the packages. What I was missing is to run the tests against a older version of the trunk. [...] Most people aren't changing these components. Nevertheless, we still have the old tree available for testing. We didn't lose anything. I can agree with, we didn't loose anything. So let's say it's not just there anymore. 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? Again, I did run the tests against the runk, but I didn't recognize that I should test my changes against a older version of packages. Probably I'm not that smart to take care on everything and was trusting on testing to much ;-) I know there is no difference between the old trunk and the new egg development testing. This error whould also happen to me if I where doing it in the old trunk setup. My problem was not test my work against a older version of the trunk. Or like Lennart told, the missing tests for integration (import changes). I personaly think, less test -- more errors. So test! What's stopping you? The old tree is still available! The crapy do it by your self test setup is stopping me really hard or at least slowing me down right now more then the it should. It's not easy to follow all the ideas behind egg, setuptools, easy_install, buildout in such a speed like we changed to this patterns. I agree Speed kills, but I think switch to eggs force us to take it all or nothing. Regards Roger Ineichen [...] Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
On Oct 2, 2007, at 9:24 AM, Roger Ineichen wrote: Hi Jim, Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors. [...] 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. That's not true. I did test the package against the trunk. But the problem was, I also adjusted the imports in the packages. hehe. This sort of practice makes any arguments for testing against the trunk kind of meaningless. What I was missing is to run the tests against a older version of the trunk. So perhaps now you want people to test against old versions of the trunk? How many old versions? A better approach would have been to add backward compatibility tests for each backward-compatibility support change you made, as Lennart suggested. Even then, to be more sure that you caught everything, you should have made the changes in two stages: 1. Refactor the package in question providing backward compatibility support, including tests of that support. Test against other unchanged packages. 2. Then change the other packages is you must. ... I know there is no difference between the old trunk and the new egg development testing. This error whould also happen to me if I where doing it in the old trunk setup. My problem was not test my work against a older version of the trunk. Or like Lennart told, the missing tests for integration (import changes). The latter. The 2-step process that we've used in the past would also have helped. I personaly think, less test -- more errors. So test! What's stopping you? The old tree is still available! The crapy do it by your self test setup is stopping me really hard or at least slowing me down right now more then the it should. Maybe it should slow you down more. It's not easy to follow all the ideas behind egg, setuptools, easy_install, buildout in such a speed like we changed to this patterns. I agree Speed kills, but I think switch to eggs force us to take it all or nothing. We probably do need more formalized testing/release methodologies. As I'm sure Tres and others will rightly point out, there's probably a lot we can learn in this area from linux distributors. In the mean time, changing packages that lots of other people depend on requires judgement and care. If you don't think you're up to it, then don't try it. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
