Hi Martjin > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- > Replacedthedependency on zope.deprecation with BBB imports > > Hey, > > Roger Ineichen wrote: > [snip] > > 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. > > I'm not sure I understand, but if you directly use > zope.formlib you should have a direct dependency on it in > your setup.py.
should is the right word for this ;-) > > 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. > > If you don't use zope.formlib, there isn't a problem. If you > do use it, you should declare it. I'm not sure I understand > the problem here. Of course the dependency refactoring will > cause breakages here and there, but I don't think they're > intractable (especially if we do provide a KGS for the > toolkit packages). > > > The deprecation message is a very important information and > can keep > > you informed on what's going on and about new better concepts. > > I think you should be reading the CHANGES.txt of the packages > you depend on when you upgrade the dependency. > > If you *don't* depend on a package directly, you normally > shouldn't have to be concerned when it disappears. Of course > there might be bugs introduced in this process: packages you > do somehow indirectly depend on disappear. That's something > we'll have to live with if we want to move forward at all. I > don't see how zope.deprecation is going to make any > difference in this in any way however - you won't see any > deprecation warnings either as the underlying package is simply gone. The point is that the deprecation message informs you for upcomming work. Which is a good information. I do not read the CHANGES.txt files ever night. > A CHANGES.txt can contain much much better information than > the deprecation warnings ever could. It can detail what > happened, why it did, and what you should be doing. I've been > rather confused with a "what now?" feeling when confronted > with deprecation warnings in the past, and there was nothing > else but these messages that I could investigate. Of corse should we have CHANGES.txt files. A deprecation warning should show a link where vi and emac users can write script which points directly to the CHANGES.txt at pypi if they click on the deprecation warning link ;-) Regards Roger Ineichen > Regards, > > Martijn > > _______________________________________________ > Zope-Dev maillist - [email protected] > 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 ) > _______________________________________________ Zope-Dev maillist - [email protected] 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 )
