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

[Martijn Faassen]

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.

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

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.

Regards,

Martijn