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

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

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

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

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

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

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