[Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports

[Roger Ineichen]

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  -  Zope-Dev at 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 )
>