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

[Roger Ineichen]

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