> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/-
> Replacedthedependency on zope.deprecation with BBB imports
> Roger Ineichen wrote:
> > 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
> > 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
> > 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 ;-)
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -