Mailing List Archive: Zope: Dev

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports

Index | Next | Previous | View Threaded

srichter at cosmos

May 25, 2009, 5:33 PM

Post #1 of 18 (1031 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports

On Monday 25 May 2009, Shane Hathaway wrote:
> +- Replaced the dependency on zope.deprecation with BBB imports

As a general question, how will people know that an import location changed?

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"
_______________________________________________
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 )

dev at projekt01

May 25, 2009, 6:33 PM

Post #2 of 18 (988 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports [In reply to]

Hi Stephan

> -----Ursprüngliche Nachricht-----
> Von: zope-dev-bounces[at]zope.org
> [mailto:zope-dev-bounces[at]zope.org] Im Auftrag von Stephan Richter
> Gesendet: Dienstag, 26. Mai 2009 02:33
> An: zope-dev[at]zope.org
> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/
> - Replaced thedependency on zope.deprecation with BBB imports
>
> On Monday 25 May 2009, Shane Hathaway wrote:
> > +- Replaced the dependency on zope.deprecation with BBB imports
>
> As a general question, how will people know that an import
> location changed?

Some people think it's better to have a nice clean log then
deprecation warnings on server startup. I still don't understand
the reason if there is any. Probably others can explain why we
skip the deprecation warnings which is a hugh win for migration
tasks.

Regards
Roger Ineichen
_____________________________
END OF MESSAGE

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

tseaver at palladion

May 25, 2009, 6:33 PM

Post #3 of 18 (987 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephan Richter wrote:
> On Monday 25 May 2009, Shane Hathaway wrote:
>> +- Replaced the dependency on zope.deprecation with BBB imports
>
> As a general question, how will people know that an import location changed?

- - By reading changelogs.

- - By running the "indirect imports checker" script on their code.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver[at]palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKG0by+gerLs4ltQ4RAjlEAKCjfN7dp0PpWvJ4R2CD1V0FqyBHdgCdHVCZ
RTj+r6K1y24r5ZN0AZnP6t8=
=7AWh
-----END PGP SIGNATURE-----

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

dev at projekt01

May 25, 2009, 6:38 PM

Post #4 of 18 (988 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports [In reply to]

Hi Tres

> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/
> - Replaced the dependency on zope.deprecation with BBB imports
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephan Richter wrote:
> > On Monday 25 May 2009, Shane Hathaway wrote:
> >> +- Replaced the dependency on zope.deprecation with BBB imports
> >
> > As a general question, how will people know that an import
> location changed?
>
> - - By reading changelogs.
>
> - - By running the "indirect imports checker" script on their code.

Sound interesting, what's an "indirect imports checker" script?

Regards
Roger Ineichen
_____________________________
END OF MESSAGE

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

faassen at startifact

May 26, 2009, 3:40 AM

Post #5 of 18 (982 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports [In reply to]

Stephan Richter wrote:
> On Monday 25 May 2009, Shane Hathaway wrote:
>> +- Replaced the dependency on zope.deprecation with BBB imports
>
> As a general question, how will people know that an import location changed?

CHANGES.txt.

Christian Theune wrote a test runner extension a few months ago that can
tell people there is a more direct import available. It still hasn't
been released, though...

Christian also wrote a tool (status unclear too) that can update an
existing ZODB in the case of persistent objects.

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 )

faassen at startifact

May 26, 2009, 3:41 AM

Post #6 of 18 (985 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports [In reply to]

Hi there,

Roger Ineichen wrote:
>
> Sound interesting, what's an "indirect imports checker" script?

Code that Christian Theune should fold into zope.testing as soon as
possible. :)

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 )

reinout at vanrees

May 27, 2009, 2:38 AM

Post #7 of 18 (966 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports [In reply to]

On 2009-05-26, Roger Ineichen <dev[at]projekt01.ch> wrote:
> Some people think it's better to have a nice clean log then
> deprecation warnings on server startup. I still don't understand
> the reason if there is any. Probably others can explain why we
> skip the deprecation warnings which is a hugh win for migration
> tasks.

Main reason: often you get buried in deprecation warnings which then drown out
potentially more important warnings.

When migrating: yes, such deprecation warnings are handy. But in 99% of the
cases you'll just be *using* the various libraries and you still get a load of
warnings.

Complaints/questions about the huge list of deprecation warnings in earlier
plone versions were a regular occurrence on the mailinglists.

So: yes, there's a reason. Perhaps not the best one, but still.

Reinout

--
Reinout van Rees - reinout[at]vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"

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

dev at projekt01

May 27, 2009, 5:06 AM

Post #8 of 18 (965 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports [In reply to]

Hi Reinout

> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/
> - Replacedthedependency on zope.deprecation with BBB imports
>
> On 2009-05-26, Roger Ineichen <dev[at]projekt01.ch> wrote:
> > Some people think it's better to have a nice clean log then
> > deprecation warnings on server startup. I still don't
> understand the
> > reason if there is any. Probably others can explain why we skip the
> > deprecation warnings which is a hugh win for migration tasks.
>
> Main reason: often you get buried in deprecation warnings
> which then drown out potentially more important warnings.
>
> When migrating: yes, such deprecation warnings are handy.
> But in 99% of the cases you'll just be *using* the various
> libraries and you still get a load of warnings.
>
> Complaints/questions about the huge list of deprecation
> warnings in earlier plone versions were a regular occurrence
> on the mailinglists.
>
>
> So: yes, there's a reason. Perhaps not the best one, but still.

I think there is something else wrong if someone is using
code with deprecation warnings in a production setup.

The deprecation warning should never show up on a production
server because you have to make sure that you don't use
deprecated code. That's the only goal of the deprecation system.

Your reason says that you like to use packages
with deprecated code in a production setup. On the other
side developer which take care on deprecated code can't be
sure that we use deprecateded code or not. That's not nice.

I was afraid excatly of this use case. Skiping deprecation
warnings is a workarround for official release and use
deprecated code instead of update everything.

A good solution whould prevent to use deprecated code
in a production setup and not only skip the deprecation
warnings because we as developer know that this will
also works.

btw,
I also think indirect imports are not the same as
deprecated imports. Of corse a deprecated import is
a indirect import but a indirect import is not implicit
a deprecated import. That's just a very ugly pattern
for do something which should be done in another way.

Parsing "# BBB" comments whould be a better solution
for find deprecated imports.

Regards
Roger Ineichen

> Reinout
>
> --
> Reinout van Rees - reinout[at]vanrees.org -
> http://reinout.vanrees.org Software developer at
> http://www.thehealthagency.com "Military engineers build
> missiles. Civil engineers build targets"
>
> _______________________________________________
> 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 )
>

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

faassen at startifact

May 27, 2009, 6:42 AM

Post #9 of 18 (963 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports [In reply to]

Hi there,

Before we have this discussion yet again, I will record the official
stance in the zope toolkit decisions document, and I'll quote it here:

* When code moves to a new location to import it from (in the same or
another package), use a ``from foo import bar`` statement, with a
``#BBB`` comment to indicate the import is only there to support
backwards compatibility.

In the CHANGES.txt of a package, state that an import location got
deprecated and where the new location is (making this a feature
release, not a bugfix release).

Reasons:

* it avoid a dependency on zope.deprecation, which is quite involved
in its implementation, using proxies.

* A ``from .. import ..`` is immediately comprehensible to any
Python programmer as well as tools.

* Deprecation warnings make it hard to write a library that supports
multiple versions of another library; a change in an indirect
dependency can create deprecation warnings that the original
developer does not care about.

* We are in the process of developing a testrunner extension that
will report on indirect imports, and a ZODB upgrade procedure.

Feel free to discuss it, either to add arguments to refine this, or to
attempt to overthrow this decision entirely.

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 )

dev at projekt01

May 27, 2009, 8:09 AM

Post #10 of 18 (963 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports [In reply to]

Hi Martijn

> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/
> - Replacedthedependency on zope.deprecation with BBB imports
>
> Hi there,
>
> Before we have this discussion yet again, I will record the
> official stance in the zope toolkit decisions document, and
> I'll quote it here:
>
> * When code moves to a new location to import it from (in the same or
> another package), use a ``from foo import bar`` statement, with a
> ``#BBB`` comment to indicate the import is only there to support
> backwards compatibility.
>
> In the CHANGES.txt of a package, state that an import location got
> deprecated and where the new location is (making this a feature
> release, not a bugfix release).
>
> Reasons:
>
> * it avoid a dependency on zope.deprecation, which is
> quite involved
> in its implementation, using proxies.
>
> * A ``from .. import ..`` is immediately comprehensible to any
> Python programmer as well as tools.
>
> * Deprecation warnings make it hard to write a library
> that supports
> multiple versions of another library; a change in an indirect
> dependency can create deprecation warnings that the original
> developer does not care about.
>
> * We are in the process of developing a testrunner extension that
> will report on indirect imports, and a ZODB upgrade procedure.
>
> Feel free to discuss it, either to add arguments to refine
> this, or to attempt to overthrow this decision entirely.

The only thing I could say about this concept is that we
didn't start to remove #BBB marked imports.

Just wait till we start remove the BBB imports and
the packages from install_requires ...

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

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

slinkp at gmail

May 27, 2009, 12:36 PM

Post #11 of 18 (954 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports [In reply to]

On Wed, May 27, 2009 at 02:06:03PM +0200, Roger Ineichen wrote:
> I think there is something else wrong if someone is using
> code with deprecation warnings in a production setup.

Do you not use any third-party code?

Often, the deprecation warnings are emitted by code not under your
control.

- PW

--

Paul Winkler
http://www.slinkp.com
_______________________________________________
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 )

dev at projekt01

May 27, 2009, 2:07 PM

Post #12 of 18 (955 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

Hi Paul

> Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/-
> Replacedthedependency on zope.deprecation with BBB imports
>
> On Wed, May 27, 2009 at 02:06:03PM +0200, Roger Ineichen wrote:
> > I think there is something else wrong if someone is using code with
> > deprecation warnings in a production setup.
>
> Do you not use any third-party code?

No not really, just python, zope and z3c libraries,
on windows some win32 or ctypes.

> Often, the deprecation warnings are emitted by code not under
> your control.

I think using packages with deprecated code is just a workarround
if someone needs to use new features which is built in a
newer version of a package and can't use all the newer
versions of the packages this package depends on. (BBB)

The better way is to use the old package or the new set of packages.
I agree that this is not always possible. But we should not
excuse us and tink that this is correct. It still has a hugh
potential of problems because the set of versions is based
on BBB and this part is not well tested or test are removed.

Most the time if you will run into unexpected problems,
some untested old BB code is involved. Take a look at the
old registry code in our zope packages as a sample.

Regards
Roger Ineichen

> - PW
>
>
> --
>
> Paul Winkler
> http://www.slinkp.com
> _______________________________________________
> 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 )
>

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

srichter at cosmos

May 27, 2009, 4:02 PM

Post #13 of 18 (952 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

On Wednesday 27 May 2009, Roger Ineichen wrote:
> I think using packages with deprecated code is just a workarround
> if someone needs to use new features which is built in a
> newer version of a package and can't use all the newer
> versions of the packages this package depends on. (BBB)
>
> The better way is to use the old package or the new set of packages.
> I agree that this is not always possible. But we should not
> excuse us and tink that this is correct. It still has a hugh
> potential of problems because the set of versions is based
> on BBB and this part is not well tested or test are removed.
>
> Most the time if you will run into unexpected problems,
> some untested old BB code is involved. Take a look at the
> old registry code in our zope packages as a sample.

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.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"
_______________________________________________
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 )

faassen at startifact

May 28, 2009, 3:50 AM

Post #14 of 18 (940 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports [In reply to]

Hi there,

Roger Ineichen wrote:
[snip]
> The only thing I could say about this concept is that we
> didn't start to remove #BBB marked imports.
>
> Just wait till we start remove the BBB imports and
> the packages from install_requires ...

Since we were hardly in a hurry removing deprecation warnings *years*
after we promised to remove them in the text (there's still some
around), I can't say we'll be in that much of a hurry to remove these. :)

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 )

faassen at startifact

May 28, 2009, 3:55 AM

Post #15 of 18 (940 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

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?

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.

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.

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 )

dev at projekt01

May 28, 2009, 5:17 AM

Post #16 of 18 (941 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

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

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

faassen at startifact

May 28, 2009, 5:58 AM

Post #17 of 18 (938 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

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

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

dev at projekt01

May 28, 2009, 6:18 AM

Post #18 of 18 (938 views)
Permalink

Re: [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports [In reply to]

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

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com