Hi Martijn
Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hey,
Stephan Richter wrote: [snip]
I have been following this discussion and just want to mention that I fully agree with Roger. If you release a final version of Zope or a package that spews deprecation warnings or has not fixed the imports, then this should be considered bad releasing.
I'm not sure I understand this. If you are releasing a final version of zope.app.component, do you want it *not* to spew deprecation warnings?
My fear is that deprecated imports will pull in packages and act as the single point of an egg declaration. If someone removes a dependency during a deprecation import cleanup lets say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a custom project didn't fix the zope.formlib depndency in his setup.py because there is no need to do so. Good luck if the last egg cleans up the zope.formlib dependency and you didn't fix it in your project for your self. This will end in loosing the dependency at all and you don't know why. Of corse you can fix this lost dependency and add it to your setup.py. But you still don't know why. You also can't find information about why in the zope.formlib package is not needed anymore because another package is responsible for not using the zope.formlib package. I''m pretty sure that at this moment you like to know if you should still like to depend on zope.formlib or not and also change to something else, but to what? What get refactored and is not using zope.formlib anymore? With deprecation warnings, you get very early informed and you will see which package are using newer versions. This will give you the required information that you also should switch a to another better concept. The deprecation message is a very important information and can keep you informed on what's going on and about new better concepts. Regards Roger Ineichen
Or do you mean you require someone to go through all packages that may depend on zope.app.component and change the imports there before zope.app.component is released? But if so, you'd need to release zope.app.component with deprecation warnings.
I'm absolutly sure you should not release packages in a KGS with deprecation warnings or deprecated imports. Of corse there could be a package which uses deprecated imports because another package get refactored. but not in a KGS. I think this is an important point. We agree that there could be packages with deprecated imports. but the release manager of the KGS has to do all the work for a clean deprecation free KGS release. That's a pain for them.
Several times in the previous discussion I heard people talk about wanting to support multiple releases of a single package and not wanting indirect deprecation warninsg. I'm not going to defend their view here myself, but I must note we've been spending some months now moving away from zope.deprecation.
I highly doubt that this will hurt us seriously in the coming years. And if it does, at least we'll be using Python imports amenable by analysis by any Python programmer, with records in the CHANGES.txt that can be read by anyone, and not our own home-grown import system using module proxies.
The current situation without deprecation warnings requires to read and follow 100 - 115 CAHNGES.txt files for some of our projects. That's just a pain. And I'm pretty sure nobody which proposes to skip deprecation messages and uses such an amount of packages is reading every CHANGES.txt file. I'm 100% sure nobody not invloved in the core development is happy with reading such an amount of CHANGES.txt files. And as more as I think about our concept I think it's totaly wrong. It's just bad to officialy recommend that everybody should read the CHANGEs.txt or he get lost in working with Zope packages. Note if you will loose a dependency(egg) you can't read the CHANGES.txt file of the lost package, you have to find out why you lost the dependency an consult all CHANGES.txt files from all of your used packages. Regards Roger Ineichen
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )