Hi there, I saw that Roger Ineichen created and released a package called zope.browser. I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me? Regards, Martijn
Martijn Faassen wrote:
Hi there,
I saw that Roger Ineichen created and released a package called zope.browser.
I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me?
Looking more, I've noticed that zc.sourcefactory replaces the dependency on zope.app.form with this package. That seems to be an improvement. Since I'm quite interested in this project, I'd like to hear much more about how we will determine which kind of dependency surgery we'll do next. Regards. Martijn
Hi Martijn
Betreff: Re: [Zope-dev] zope.browser?
Martijn Faassen wrote:
Hi there,
I saw that Roger Ineichen created and released a package called zope.browser.
I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me?
Looking more, I've noticed that zc.sourcefactory replaces the dependency on zope.app.form with this package. That seems to be an improvement.
Since I'm quite interested in this project, I'd like to hear much more about how we will determine which kind of dependency surgery we'll do next.
I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form) I didn't see any other (browser) interface which should go to this package because of real dependency problems yet. But sure if you see something which can solve problems, feel free to move interfaces, dependency less components or helper methods to this package. I think everything which goes to zope.browser must take very care on dependencies. I guess one important rule should be, zope.browser should depend on anything. Probably an exception whould be zope.schema, zope.messageid. Any other ideas? 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, Am Donnerstag, den 11.12.2008, 17:13 +0100 schrieb Roger Ineichen:
I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form)
I didn't see any other (browser) interface which should go to this package because of real dependency problems yet. But sure if you see something which can solve problems, feel free to move interfaces, dependency less components or helper methods to this package.
We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerston... might be a candidate for this or such a component. We use it most of the time as mixin for browser views, content providers, menu items and everything else which has to deal with application state data, urls and queries. For IRequestMixin the implementation is almost finished (one function and some testing left - see base.py and base.txt if you're interested in), and for the pointed usecases there are convenience implementations. It would be great to see this or something like this in zope.browser package, dealing with request data and url's is almost every day's business and always more code than i could be. regards, robert
I think everything which goes to zope.browser must take very care on dependencies.
I guess one important rule should be, zope.browser should depend on anything. Probably an exception whould be zope.schema, zope.messageid.
Any other ideas?
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 )
_______________________________________________ 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 there, Robert Niederreiter wrote: [snip]
We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here
http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerston...
might be a candidate for this or such a component.
While this is certainly an interesting package, I think the idea behind zope.browser is to keep dependencies to an absolute minimum. I'm not sure I see the point of just putting the *interface* "IRequestMixin" in zope.browser, and the implementation would almost certainly pull in more dependencies, right? (by the way, an interface called 'Mixin'? Isn't the mixin nature a property of a class, not an interface?) I think we should be careful not to introduce more functionality into zope.browser right now that isn't moved from some other zope.* package. The goal after all, as I understand it, is to reduce installation dependencies. Regards, Martijn
Am Donnerstag, den 11.12.2008, 18:18 +0100 schrieb Martijn Faassen:
Hi there,
Robert Niederreiter wrote: [snip]
We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here
http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerston...
might be a candidate for this or such a component.
While this is certainly an interesting package, I think the idea behind zope.browser is to keep dependencies to an absolute minimum. I'm not sure I see the point of just putting the *interface* "IRequestMixin" in zope.browser, and the implementation would almost certainly pull in more dependencies, right? It would be possible to strip the implementation dependencies down to zope.interface and zope.component if IAbsoluteUrl (iirc) is moved as well and the ICookiePrefix default implementation returns something static.
(by the way, an interface called 'Mixin'? Isn't the mixin nature a property of a class, not an interface?) Yes ;), the naming is not the best choice. The intention was to hint the reader how an implementation of this interface is supposed to be used.
I think we should be careful not to introduce more functionality into zope.browser right now that isn't moved from some other zope.* package. The goal after all, as I understand it, is to reduce installation dependencies.
you queried ideas. right? regards, robert
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 )
-- Robert Niederreiter IT-Architecture & Engineering Aflingerstraße 7 A-6176 Völs +43 699 160 20 192 +43 512 89 00 77 Squarewave Computing WEB APPLICATIONS, ZOPE, PLONE, HOSTING BlueDynamics Alliance production: concept, development, design http://squarewave.at consulting: analysis, coaching, training http://bluedynamics.com management: projects, process, community
On Thursday 11 December 2008, Martijn Faassen wrote:
I think we should be careful not to introduce more functionality into zope.browser right now that isn't moved from some other zope.* package. The goal after all, as I understand it, is to reduce installation dependencies.
+1 Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi Martijn
Betreff: Re: [Zope-dev] zope.browser?
[...]
I think we should be careful not to introduce more functionality into zope.browser right now that isn't moved from some other zope.* package. The goal after all, as I understand it, is to reduce installation dependencies.
Yes, absolutly, nothing else right now. I came to a point where I really like to get rid of zope.app.rotterdam, zope.app.authentication and many other packages in my simple project setup. Right now, we have a very nice component architecture, but we can't use them as we like. There are to many packages grouped together with each other on zcml level or for just for using some minimal things. The next step whould be moving the IPasswordManager implementation from zope.app.authentication to zope.app.security. This makes it possible to provide a zope.app.authentication less zope.app.testing package. Also zope.app.keyreference and zope.app.intid should get ported to zope.* packages. Another part which I'll cleanup is the zope.app.i18n configure.zcml. This zcml file registers in line: 5 -28 different components from totaly different packages. Each of them should go to the right package where the components are defined. It doesn't make sense to configure them in zope/app/i18n/confiure.zcml. btw All I like to do is to remove the dependencies which are not needed for a minimal installation. But everything should be backward compatible and just work like before. I will not introduce new dependencies or implement new components. It's all about cleanup existing things. But as far as I can see, most people are happy with removing dependencies and make progress in this direction. Any participation or discussion is very welcome! I just like to keep the discussion to a minimum and be a more productive. I'll promiss to take care and do nothing which doesn't make sense. Does this Ok and does it make sense for you? Regards Roger Ineichen
Hi Robert
Betreff: Re: [Zope-dev] zope.browser?
Hi,
Am Donnerstag, den 11.12.2008, 17:13 +0100 schrieb Roger Ineichen:
I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form)
I didn't see any other (browser) interface which should go to this package because of real dependency problems yet. But sure
if you see
something which can solve problems, feel free to move interfaces, dependency less components or helper methods to this package. We have written browser helper tools in a package named cornerstone.browser. especially IRequestMixin here
http://dev.plone.org/collective/browser/cornerstone.browser/tr unk/cornerstone/browser/interfaces.py
might be a candidate for this or such a component.
I like this. But we should not mix the cleanup refactoring with any other new things. I think this will confuse people and will give us less aceptance for the really needed cleanup. Let's keep this pending and discuss at a later time again. Regards Roger Ineichen
On 2008-12-11 17:13:06 +0100, "Roger Ineichen" <dev@projekt01.ch> said:
Hi Martijn
Betreff: Re: [Zope-dev] zope.browser?
Martijn Faassen wrote:
Hi there,
I saw that Roger Ineichen created and released a package called zope.browser.
I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me?
Looking more, I've noticed that zc.sourcefactory replaces the dependency on zope.app.form with this package. That seems to be an improvement.
Since I'm quite interested in this project, I'd like to hear much more about how we will determine which kind of dependency surgery we'll do next.
I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form)
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hey, Christian Zagrodnick wrote: [snip]
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? Regards, Martijn
On Fri, Dec 12, 2008 at 02:24:09PM +0100, Martijn Faassen wrote:
Hey,
Christian Zagrodnick wrote: [snip]
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this encourage people to update their code?
One issue is that it's impossible to write code that's "deprecation warning free" and works across multiple versions of dependencies. That forces people to become accustomed to seeing and ignoring deprecation warnings.
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 )
-- Brian Sutherland
On 2008-12-12 14:24:09 +0100, Martijn Faassen <faassen@startifact.com> said:
Hey,
Christian Zagrodnick wrote: [snip]
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this encourage people to update their code?
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick:
On 2008-12-12 14:24:09 +0100, Martijn Faassen <faassen@startifact.com> said:
Hey,
Christian Zagrodnick wrote: [snip]
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this encourage people to update their code?
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it.
the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) regards, robert
On 2008-12-12 16:04:09 +0100, Robert Niederreiter <rnix@squarewave.at> said:
Hi,
Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick:
On 2008-12-12 14:24:09 +0100, Martijn Faassen <faassen@startifact.com> said:
Hey,
Christian Zagrodnick wrote: [snip]
That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this encourage people to update their code?
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it.
the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;)
No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Christian
Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
[...]
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it.
the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;)
No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes.
The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here.
This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. btw, we also should deprecate the ISite interface at the old location. Regards Roger Ineichen
On 2008-12-15 13:44:43 +0100, "Roger Ineichen" <dev@projekt01.ch> said:
Hi Christian
Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
[...]
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it.
the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;)
No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes.
The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here.
This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface.
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove.
Depends. See below.
I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages.
If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places.
I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it?
In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that.
Yes, for necessary API changes which do not need to be shipped immeadiately I can see that.
btw, we also should deprecate the ISite interface at the old location.
Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Christian
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
On 2008-12-15 13:44:43 +0100, "Roger Ineichen" <dev@projekt01.ch> said:
Hi Christian
Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
[...]
A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it.
the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;)
No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes.
The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here.
This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface.
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
The reason why we should deprecate interfaces is: If a
package still
points to the old interface location, this package whould bring in the old dependency we tried to remove.
Depends. See below.
I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages.
If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places.
I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it?
In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out
of date and
we have no change to know about that.
Yes, for necessary API changes which do not need to be shipped immeadiately I can see that.
btw, we also should deprecate the ISite interface at the old location.
Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings.
All I can say about that is: If there is an improvment in the API we need to announce that. Otherwise other developer will not follow or follow at a time they think it's better for them. Or even worse, they don't know about that. Deprecation messages will kick them a little bit and they get forced to update their code in a acceptable way ;-) The question now is, should we be lazy and skip this information and support nice deprecation free test output or support developer with information about the newest API changes in form of deprecation message hints? Regards Roger Ineichen
Christian Zagrodnick wrote: [snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision. There was a decision to "avoid deprecation" made by it doesn't seem to be motivated in the discussion: "- zope.app.component.interfaces then can import ISite from the new place to avoid deprectation." You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking? I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Christian Zagrodnick wrote: [snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision. There was a decision to "avoid deprecation" made by it doesn't seem to be motivated in the discussion:
"- zope.app.component.interfaces then can import ISite from the new place to avoid deprectation."
You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking?
I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background.
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJSBNN+gerLs4ltQ4RAgQUAJsHvpghzkycXNYlOOYC82lCTlUAXQCfT9B0 zIWGClCUqiD/irMMaxwwJzw= =kskl -----END PGP SIGNATURE-----
Hi Tres
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
[...]
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me! This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore. If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code. This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output. Regards Roger Ineichen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:
Hi Tres
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
[...]
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me!
This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore.
If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code.
This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output.
I think you missed my point: third-party developers who want their code *not* to emit the deprecation warnings when used across both old and new versions of "our" library have to add nasty BBB cruft to *their* code: we've shifted the BBB burden to them, often for a small marginal benefit to ourselves. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJSUMo+gerLs4ltQ4RAuncAKCS9HL5XlvjHQoI1Y/6IwVJ2+c7iACfSFcj wyqDo/8Qgd1Om79oyLjy7yA= =kenJ -----END PGP SIGNATURE-----
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martijn Faassen wrote:
Christian Zagrodnick wrote: [snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision. There was a decision to "avoid deprecation" made by it doesn't seem to be motivated in the discussion:
"- zope.app.component.interfaces then can import ISite from the new place to avoid deprectation."
You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking?
I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background.
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
This is my issue as well. http://docs.python.org/library/warnings.html#module-warnings We could use PendingDeprecationWarning for recently deprecated code and then convert that to DeprecationWarning once an alternative has been available for some time. That way, people like Roger would be able to get all recent deprecation warnings by using the -Wd command line option to python, but they wouldn't be shown by default. # python2.4 -Wd >>> import warnings >>> warnings.warn("deprecated", PendingDeprecationWarning) __main__:1: PendingDeprecationWarning: deprecated # python2.4 >>> import warnings >>> warnings.warn("deprecated", PendingDeprecationWarning) There's probably some caveat as to why this won't work, but it seems like it should by looking at the documentation. -- Brian Sutherland
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
Martijn Faassen wrote:
Christian Zagrodnick wrote: [snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision. There was a decision to "avoid deprecation" made by it doesn't seem to be motivated in the discussion:
"- zope.app.component.interfaces then can import ISite from the new place to avoid deprectation."
You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking?
I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background.
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
Also consider deprecation messages triggered not by code, but by the use in existing ZODB databases. ISite is often directlyProvided by persistent objects, which makes the ZODB store a fully-qualified interface name. You'd need an evolution script to walk the container tree and force a repickling of every site to prevent the app from spewing deprecation warnings at runtime. Regards, -- http://pov.lt/ -- Zope 3 consulting and development
Marius Gedminas wrote:
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote: [why would we ever want to avoid giving deprecation warnings?]
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
Also consider deprecation messages triggered not by code, but by the use in existing ZODB databases. ISite is often directlyProvided by persistent objects, which makes the ZODB store a fully-qualified interface name. You'd need an evolution script to walk the container tree and force a repickling of every site to prevent the app from spewing deprecation warnings at runtime.
I don't understand Tres' issue very well; I'm with Roger in that deprecation warnings are there for a reason. That said if there's an easier way to shut them up for people who don't want to bother with them immediately that sounds reasonable. PendingDeprecationWarning as Brian points out sounds like something we should look into. The ZODB issue I do understand and perhaps that is the effect Tres is pointing to as well. I hadn't realized that ISite was pickled frequently. This may make it different from ITerms, which I assume isn't generally pickled. If we can get PendingDeprecationWarning working, people like Roger can keep refactoring without bothering too many people and still get the deprecation warnings they want to see. Then at some stage when a new release of a framework (Zope 3, Grok, Zope 2) is made, we could convert these warnings into true DeprecationWarnings and provide upgrade code for ZODB-level code. Or even not - the Grok project could for instance just have the policy not to release with any PendingDeprecationWarnings present either. For things we know never get pickled, we could choose to use DeprecationWarning right away. This might run into Tres' issue, which I don't quite understand yet. :) How does that sound? Regards, Martijn
On Wed, Dec 17, 2008 at 8:31 AM, Martijn Faassen <faassen@startifact.com> wrote:
If we can get PendingDeprecationWarning working, people like Roger can keep refactoring without bothering too many people and still get the deprecation warnings they want to see. Then at some stage when a new release of a framework (Zope 3, Grok, Zope 2) is made, we could convert these warnings into true DeprecationWarnings and provide upgrade code for ZODB-level code. Or even not - the Grok project could for instance just have the policy not to release with any PendingDeprecationWarnings present either.
For things we know never get pickled, we could choose to use DeprecationWarning right away. This might run into Tres' issue, which I don't quite understand yet. :)
How does that sound?
Even though I don't mind deprecation warnings as they are, a provisional +1 from me; I too would like to hear more about Tres' scenario. -- Benji York Senior Software Engineer Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Marius Gedminas wrote:
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote: [why would we ever want to avoid giving deprecation warnings?]
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions. Also consider deprecation messages triggered not by code, but by the use in existing ZODB databases. ISite is often directlyProvided by persistent objects, which makes the ZODB store a fully-qualified interface name. You'd need an evolution script to walk the container tree and force a repickling of every site to prevent the app from spewing deprecation warnings at runtime.
I don't understand Tres' issue very well; I'm with Roger in that deprecation warnings are there for a reason. That said if there's an easier way to shut them up for people who don't want to bother with them immediately that sounds reasonable. PendingDeprecationWarning as Brian points out sounds like something we should look into.
The ZODB issue I do understand and perhaps that is the effect Tres is pointing to as well. I hadn't realized that ISite was pickled frequently. This may make it different from ITerms, which I assume isn't generally pickled.
If we can get PendingDeprecationWarning working, people like Roger can keep refactoring without bothering too many people and still get the deprecation warnings they want to see. Then at some stage when a new release of a framework (Zope 3, Grok, Zope 2) is made, we could convert these warnings into true DeprecationWarnings and provide upgrade code for ZODB-level code. Or even not - the Grok project could for instance just have the policy not to release with any PendingDeprecationWarnings present either.
For things we know never get pickled, we could choose to use DeprecationWarning right away. This might run into Tres' issue, which I don't quite understand yet. :)
I take cleaning up deprecation warnings seriously: I want all tests for my packages, for instance, to run without emitting *any* of them. Deprecation warnings have a non-trivial downside: consider the case wher one of *my* downstream users updates Roger's pacakge (e.g., to pick up a critcial security fix, or something). My package has dependencies which allow this (because I don't put hard pins in library packages), but now *my* package now emits warnings, where it didn't before. In order to accomplish the goal of deprecation cleanliness, I can either: - Update my dependency requirements to point to only the newest versions of the code which adds the warnings. My users are now forced to upgrade as well, which may cause their apps to break. - Add conditional imports to my code, which tries the "blessed" location first and then falls back to the "deprecated" location. This is the "cost transference" I was speaking of: my code gets cruftier, just so Roger's can be "clean". If we just leave the name importable from the old location, what is hurt? The major downside is that people won't learn about the new location. I consider this to be less an issue than the two problems I outline above. Even if the "pending warning" bit works, I still have to add the BBB cruft to my code to future-proof it. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD4DBQFJSY0F+gerLs4ltQ4RAqkNAJ9BcBPXiW3jZBv2hInmvLeUEdajUACYxZh+ PlGE+sB2GloP2iyl/yW+aw== =ygv/ -----END PGP SIGNATURE-----
On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver <tseaver@palladion.com> wrote:
If we just leave the name importable from the old location, what is hurt? The major downside is that people won't learn about the new location. I consider this to be less an issue than the two problems I outline above.
Agreed. Moving things around in public packages without preserving backward compatibility creates real nuisances, and just not generating warnings avoids lots of pain. This doesn't mean that you can't teach people about new locations; you just don't need to do it every time they run your code. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver <tseaver@palladion.com> wrote:
If we just leave the name importable from the old location, what is hurt? The major downside is that people won't learn about the new location. I consider this to be less an issue than the two problems I outline above.
Agreed. Moving things around in public packages without preserving backward compatibility creates real nuisances, and just not generating warnings avoids lots of pain.
Nobody was talking about breaking backwards compatibility. The whole idea is that the moving around doesn't break compatibility. Or do you consider it that the act of sending warnings itself breaks compatibility?
This doesn't mean that you can't teach people about new locations; you just don't need to do it every time they run your code.
That's a nice handwave, but what infrastructure do you propose to teach users about new locations? The current infrastructure is automatic, and I hope you're not proposing something in a text file somewhere as a replacement. The problem, I take it, is that the mere act of importing causes a warning to be sent. A tool that could scan code for import deprecations and give warnings would perhaps be preferrable. The deprecations would still need to be marked somewhere so that the tool can pick up on them, but they simply won't emit any warnings anymore. Who is going to build this infrastructure? Regards, Martijn
Hey, Tres Seaver wrote: [snip]
I take cleaning up deprecation warnings seriously: I want all tests for my packages, for instance, to run without emitting *any* of them. Deprecation warnings have a non-trivial downside: consider the case wher one of *my* downstream users updates Roger's pacakge (e.g., to pick up a critcial security fix, or something). My package has dependencies which allow this (because I don't put hard pins in library packages), but now *my* package now emits warnings, where it didn't before.
You should, and likely are, shipping your package with a recommended list of versions. If your user upgrades beyond that recommended list of versions, then that user knows that any problems that may occur are his own responsibility. A deprecation warning is hardly a disastrous thing to swallow if you're fixing a security bug. I'd also argue that deprecation warnings and security bug fixes should generally not be introduced in the same release, as deprecation should be considered to be a feature change. Anyway, the problem of your downstream users is worse. If you depend on x.y, and Roger makes it so that x.y doesn't depend on a.b anymore, and your downstream user updates to Roger's version of x.y, they will suddenly have breaking *imports* as they happened to be relying on things in a.b which just happened to get pulled in too. [snip]
If we just leave the name importable from the old location, what is hurt? The major downside is that people won't learn about the new location.
Yes, the hurt is that we aren't actually signalling the deprecation of the old location. If the goal is to reduce the dependencies between packages, it's pretty nice if people can follow this in their own packages so that *they* can benefit from less useless dependencies being pulled in as well.
I consider this to be less an issue than the two problems I outline above. Even if the "pending warning" bit works, I still have to add the BBB cruft to my code to future-proof it.
Why? Your downstream users won't see any warnings. Regards, Martijn
Martijn Faassen wrote at 2008-12-18 16:27 +0100:
... You should, and likely are, shipping your package with a recommended list of versions.
Apparently, "grok" was forced to go this route. But, in principle, this is undesirable. Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested). In the past, I have seen excessive deprecation warnings and had the feeling that the warning feature is overused (as many new features). -- Dieter
Hey, On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer <dieter@handshake.de> wrote:
Martijn Faassen wrote at 2008-12-18 16:27 +0100:
... You should, and likely are, shipping your package with a recommended list of versions.
Apparently, "grok" was forced to go this route. But, in principle, this is undesirable.
No, it's very desirable if you want to provide a stable platform at all. A platform is *not* stable if each time a new user installs it he might end up with a different set of "latest" versions - there's just no way to communicate about bugs if it's that way. It's also just not right to force all the users of a framework to make the determination which version to use for dozens of packages. The idea of using a framework is to make life easier, not harder.
Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested).
What will you do once Zope 2 is split up into multiple packages? How would you express such a thing about Zope 3 if there is no canonical list of versions (such as KGS)? Grok is in the position of Zope 2 or Zope 3 here. Of course we prefer the individual components that Grok is composed of, and extensions to Grok, to work with multiple versions of Grok. That's unrelated to the need to actually *have* versions of Grok in the first place. It's desirable to have each component work with a range of versions of other components. It's also desirable to make a collection of components work out of the box with a well-known set of versions that can be communicated about, because this selection itself has a version number as well.
In the past, I have seen excessive deprecation warnings and had the feeling that the warning feature is overused (as many new features).
I think it's clear that many people do not like seeing deprecation warnings during startup and runtime and that it's been quite a burden on developers. I can see how it is frustrating to developers (one or multiple steps away)/ It's also clear to me that if we want Zope 3 to move forward, we need a much less convoluted dependency structure and have the ability to do some relatively bold refactoring. We will therefore need to move things around a lot more, and I fully intend to make progress on that, and join Roger in his work. I therefore propose we make a new kind of deprecation system that uses the same system to mark up source code as we have now, but does never emit the warnings during run-time. Instead we create an external scanning tool that can report about deprecated imports in a package (and perhaps help fix them automatically). Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: <snip platform / KGS stuff> For the case of *library* packges, rather than platforms, forcing users into lockstep on dependencies is less desirable. Example - -------- Assume that developer Fred releases a given library distribution, 'foo-1.2.tar.gz', with the following dependency in its setup.py:: install_requires=['bar >= 0.9'] And inside the 'foo' package, some module does the following import:: from bar.baz import someAPI At the time this version of foo is released, the following versions of 'bar' are available from Barney's website: bar-0.9.tar.gz bar 1.0.tar.gz bar-1.0.1.tar.gz None of those 'bar' versions have a deprecation for the import above, and so code which uses the 'foo' package emits no warnings. At some point, Barney decides to refactor the 'bar' package, and moves 'someAPI' from the 'baz' module to a new 'qux' module. If nothing else in 'baz' *uses* 'someAPI', Barney has two choices: - - Import the symbol for BBB, and leave it "forever":: from bar.qux import someAPI # BBB - - Import it for BBB, but mark it deprecated:: import zope.deprecation # note new dependency! zope.deprecation.deprecated('someAPI', 'Usually a multi-line explanation here') from bar.qux import soemAPI # BBB The issue is moot if the 'baz' module actually uses the moved symbol. Nobody actually puts deprecation warnings around non-BBB imports created during refactorings if the module doing the import actually uses the symbol. Note that Barney is *adding* cruft to 'baz' (the several lines of stuff to this module to spell the deprection), and that he has created a future maintenance burden (ripping out the import / deprecation at some point in the future). Then look what happens to Wilma's application which uses 'foo', and transitively depend on 'bar': once she updates to bar 1.1 (e.g., to pick up an unrelated bugfix), her application begins to emit warning messages, even though the application doesn't use the deprecated symbol directly. Either Wilma must live with the warning, or else she leans on Fred to release a new version of 'foo'. Note that the relased version of 'foo' continues to *work* with baz >= 1.1 (at least until the eventual removal). Assume that 'foo' is hyper-stable, and would otherwise not need to be updated at all; Fred is now in the position of being pressured to make a gratuitous release in order mollify Wilma. If Fred *does* want to accomodate the complaints from the application author, he then has to make choices: - - Support both locations via a conditional import (AKA add cruft):: try: from baz.qux import someAPI except ImportError: from baz.bam import someAPI - - Drop support for the older location, and update the 'install_requires' accordingly. Now, users who pick up the new 'foo' version will be forced to upgrade 'bar', even if they would otherwise not want the new version.
Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested).
What will you do once Zope 2 is split up into multiple packages? How would you express such a thing about Zope 3 if there is no canonical list of versions (such as KGS)? Grok is in the position of Zope 2 or Zope 3 here.
Of course we prefer the individual components that Grok is composed of, and extensions to Grok, to work with multiple versions of Grok. That's unrelated to the need to actually *have* versions of Grok in the first place. It's desirable to have each component work with a range of versions of other components. It's also desirable to make a collection of components work out of the box with a well-known set of versions that can be communicated about, because this selection itself has a version number as well.
In the past, I have seen excessive deprecation warnings and had the feeling that the warning feature is overused (as many new features).
I think it's clear that many people do not like seeing deprecation warnings during startup and runtime and that it's been quite a burden on developers. I can see how it is frustrating to developers (one or multiple steps away)/
It's also clear to me that if we want Zope 3 to move forward, we need a much less convoluted dependency structure and have the ability to do some relatively bold refactoring. We will therefore need to move things around a lot more, and I fully intend to make progress on that, and join Roger in his work.
I therefore propose we make a new kind of deprecation system that uses the same system to mark up source code as we have now, but does never emit the warnings during run-time. Instead we create an external scanning tool that can report about deprecated imports in a package (and perhaps help fix them automatically).
I think the idea that we need to prod downstream developers to update their packages in accordance with our refactorings is suspect, especially given that both we and they have to add cruft (ours to emit the warning, theirs to suppress it). Note that all this effort / cruft is to support a hypothetical "futurue cleanliness", which only materializes when we remove our cruft and break BBB. I'm calling that win hypothetical because the warning-emitting cruft often stays in the codebase for *years*, even long after the promised removal date. Back when we were releasing a monolithic Zope3, there was at least some effort before those releases to go chase down the IOUs in the code and do the rmovals. Now that individual packages are separately released, the "maybe-ness" of the future removal is even more problematic, as the exploded, deprecation-emitting package may never even get a new release. If we that there is a real goal other than "future cleanliness" for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJTMbc+gerLs4ltQ4RAhZrAKCOdJk2keNyzAaKuNU1tMASCSRaIACffAuK jXpk6uehghc4Iv1azVitzKs= =0WfK -----END PGP SIGNATURE-----
Hi Tres
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
[...]
If we that there is a real goal other than "future cleanliness" for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer.
I think it's more then "future cleanliness". My goal is to reuse as much as we can. This means, if we deprecate "zope.app.form.browser.interface.ITerms". And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. Reegards Roger Ineichen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:
Hi Tres
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
[...]
If we that there is a real goal other than "future cleanliness" for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer.
I think it's more then "future cleanliness". My goal is to reuse as much as we can. This means, if we deprecate "zope.app.form.browser.interface.ITerms". And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects.
If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts.
I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base.
And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do.
You lose the reusability of any existing packages which supply the "old" interface / location once you finally remove the interface from the deprecated location. Unless their maintainers issue new versions of their packages (as Fred did in my example, to keep from sleeping outside with Dino in ;), your code will not be able to use both the new version of the framework *and* the old plugin at the same time. "Refactor mercilessly" is a mantra of a methodology which is specifically focused on building applications, rather tha libraries / frameworks. Once you have "downstream" users who are not actively involved in the development of your package, the costs of refactoring go up. As an example from outside Zope land: Linux developers fiercely defend their practice that there is no stable "ABI" in the kernel; out-of-tree modules have to be recompiled to be compatible with new kernel versions, including refactorings, etc. However, they are equally fierce in the policy that a user-space API, once released, is maintained *forever*. User-space code which uses such an API *must* continue to work. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJTYlG+gerLs4ltQ4RAqd7AKCpf4om3G6gpx0ilfiw1/83JgoxUgCgjBBP GBHZ4dF3Ts2UmVWKEZD5+IE= =RCah -----END PGP SIGNATURE-----
Hi there, Tres, please tell me what I should be doing as opposed to moving things around and deprecating them. I want a version of Grok with far less dependencies than it pulls in now. I believe there are a lot of advantages in doing that, and I'm not going to go into them here as I'm sure you can imagine them yourself. There are two ways I can go about that: a) break everybody's APIs and rewrite parts of Zope 3 itself so we have less dependencies for Grok. b) refactor Zope 3 itself so that there are less spurious dependencies that get pulled in. You're complaining that b) is going to cause people trouble as they see deprecation warnings. Fine, we can evolve towards a system to do deprecation warnings better. But you also seem to be suggesting we shouldn't even do b) in the first place. a) is a much greater break with the past than b), however. What is the alternative that I'm missing? Or are you suggesting we break everybody's code and go for a)? Why then arguing a smaller refactoring that tries hard to keep things working? (I expect the Grok project will involve a combination of a) and b) in the end, but hopefully as little a) as possible). It's not a theoretical cleanliness we're talking about here. zope.app.form is *not* a dependency of z3c.form anymore, and I consider this a win for z3c.form. Less code installed, and people who wade through the code won't run into the very misleading zope.app.form anymore. I've also noticed a similar win with z3c.saconfig. I forget the details, but I was very careful not to pull in a certain dependency as that pulled in all of Zope 3, and I wanted to keep dependencies under control. Then someone added a feature that needed that dependency. Then it turned out that in the mean time a new version of the dependency had been released that *didn't* pull all of Zope 3. That made me happy, as it strikes to me that a lot of small improvements like that may significantly reduce the set of dependencies many Zope 3 installations require. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hi there,
Tres, please tell me what I should be doing as opposed to moving things around and deprecating them.
I want a version of Grok with far less dependencies than it pulls in now. I believe there are a lot of advantages in doing that, and I'm not going to go into them here as I'm sure you can imagine them yourself.
There are two ways I can go about that:
a) break everybody's APIs and rewrite parts of Zope 3 itself so we have less dependencies for Grok.
b) refactor Zope 3 itself so that there are less spurious dependencies that get pulled in.
You're complaining that b) is going to cause people trouble as they see deprecation warnings. Fine, we can evolve towards a system to do deprecation warnings better.
But you also seem to be suggesting we shouldn't even do b) in the first place.
Doing b) is fine. What I am objecting to is the part where we (plan to) break imports of symbols from their old locations, instead of just leaving them importable from that place *forever*. Note that we would *not* be adding deprecation warnings in the old location if the code there (where the symbols used to live) actually used the now-refactored-to-another module symbols.
a) is a much greater break with the past than b), however. What is the alternative that I'm missing? Or are you suggesting we break everybody's code and go for a)? Why then arguing a smaller refactoring that tries hard to keep things working? (I expect the Grok project will involve a combination of a) and b) in the end, but hopefully as little a) as possible).
It's not a theoretical cleanliness we're talking about here.
zope.app.form is *not* a dependency of z3c.form anymore, and I consider this a win for z3c.form. Less code installed, and people who wade through the code won't run into the very misleading zope.app.form anymore.
I consider that a win, too. What I'm objecting to is the idea that we release a new version of *zope.app.form* which breaks imports of the symbols which used to live there. Instead, I'm arguing that we leave the BBB imports of that symbol in the old location, forever. Note that the new zope.app.form depends already on the new location of those symbols, so we aren't adding any cruft beyond a single line per symbol, along the lines of the following (I think it would be in zope.app.form.interfaces):: from zope.browser.interfaces import ITerm # BBB
I've also noticed a similar win with z3c.saconfig. I forget the details, but I was very careful not to pull in a certain dependency as that pulled in all of Zope 3, and I wanted to keep dependencies under control. Then someone added a feature that needed that dependency. Then it turned out that in the mean time a new version of the dependency had been released that *didn't* pull all of Zope 3. That made me happy, as it strikes to me that a lot of small improvements like that may significantly reduce the set of dependencies many Zope 3 installations require.
I'm in favor of reducing dependencies, and actively in favor of the refactoring which breaks apart the "dependable" bits (e.g., into the new zope.browser package) from the others. I just don't want to emit deprecation warnings now, or ImportErrors later, for imports from the old location. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJTyER+gerLs4ltQ4RAlmIAJ9SXtb8G00l9SXrxhpLFTFPEg1bOwCeLuVj +Xl2O6vkZsrLMEt4ScFgwOI= =wo9Y -----END PGP SIGNATURE-----
Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the "preferred import location" of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the "right" public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. Regards, Martijn
On 2008-12-22 18:48:47 +0100, "Martijn Faassen" <faassen@startifact.com> said:
Hi there,
All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them.
I think we need to think of some way to signal that the "preferred import location" of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely.
Right. May I remove the deprecation warning then?
I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the "right" public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end.
A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not? -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Christian
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
On 2008-12-22 18:48:47 +0100, "Martijn Faassen" <faassen@startifact.com> said:
Hi there,
All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them.
I think we need to think of some way to signal that the "preferred import location" of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely.
Right. May I remove the deprecation warning then?
Yes, but only after someone implemented another concept for notify about old import location ;-)
I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the "right" public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end.
A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not?
What is grep ;-) I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. Regrads Roger Ineichen
Hey there, Roger Ineichen wrote: [snip]
I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode?
I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB.
I don't like the use of devmode for that, especially as I hardly ever use devmode for anything (Grok doesn't really do much with it as far as I know). I prefer a tool that's external to the source code in question. You could base it off something like that importchecker (see pypi) does. It'd analyze what imports take place and whether it's importing from a place that marks itself as deprecated. Your mention of the ZODB issue brings up a good point. We'd also need a ZODB-level tool that can do this reporting in this case. The current deprecation system already covers this case, though, right? Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. The benefit is also that it'd be thorough and find all instances, not just those that happen to be in use by a particular application. Regards, Martijn
Hi Martijn
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hey there,
Roger Ineichen wrote: [snip]
I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode?
I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB.
I don't like the use of devmode for that, especially as I hardly ever use devmode for anything (Grok doesn't really do much with it as far as I know).
I prefer a tool that's external to the source code in question. You could base it off something like that importchecker (see pypi) does. It'd analyze what imports take place and whether it's importing from a place that marks itself as deprecated.
Your mention of the ZODB issue brings up a good point. We'd also need a ZODB-level tool that can do this reporting in this case. The current deprecation system already covers this case, though, right? Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. The benefit is also that it'd be thorough and find all instances, not just those that happen to be in use by a particular application.
I'm fine with any implementation. I just don't like to loose this (for me) important feature. Note; I think nobody is able to develop an application which does the cleanup right if objects get removed. At least I don't know any application where all objects get correct removed and I know different apps developed from different companies. Also my own apps don't do the cleanup correct right now. Or does someone remove items (e.g. dublin core) from the annotations for removed objects or the annotation container itself etc. etc? There is also an issue with interface references in the adapter registry. Interfaces (pickle) do not get removed. This means we really need deprecation warnings in running applications. Probably a good start whould be a script which allows to access every object in the ZODB by iter all objects and see if something raises a deprecation warning. 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 )
Martijn Faassen wrote:
Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly.
Thrawl = thrashing crawl? Never heard that word before, but it's apt. Shane
Shane Hathaway wrote:
Martijn Faassen wrote:
Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly.
Thrawl = thrashing crawl? Never heard that word before, but it's apt.
Unfortunately just a misspelling of 'trawl', which according to the jargon file means: trawl v. To sift through large volumes of data (e.g., Usenet postings, FTP archives, or the Jargon File) looking for something of interest. Regards, Martijn
Martijn Faassen wrote at 2008-12-19 22:18 +0100:
.... On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer <dieter@handshake.de> wrote:
Martijn Faassen wrote at 2008-12-18 16:27 +0100:
... You should, and likely are, shipping your package with a recommended list of versions.
Apparently, "grok" was forced to go this route. But, in principle, this is undesirable.
No, it's very desirable if you want to provide a stable platform at all. A platform is *not* stable if each time a new user installs it he might end up with a different set of "latest" versions - there's just no way to communicate about bugs if it's that way. It's also just not right to force all the users of a framework to make the determination which version to use for dozens of packages. The idea of using a framework is to make life easier, not harder.
That's your point of view -- mine is different (maybe, because my frameworks are much smaller).
Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested).
What will you do once Zope 2 is split up into multiple packages? How would you express such a thing about Zope 3 if there is no canonical list of versions (such as KGS)? Grok is in the position of Zope 2 or Zope 3 here.
My components will only depend on some of the (future) Zope 2 components in an essential way. Others may significantly change without a serious effect on my components. Thus, I will document in a way similar to "tested with Zope 2.8, 2.9, 2.10; ZODB 3.2, 3.3, 3.4". -- Dieter
On Thu, Dec 11, 2008 at 03:20:25PM +0100, Martijn Faassen wrote:
I'm sure there's a bit of the plan I don't understand yet - please enlighten me?
AFAIKR, it's a package that mostly contains interfaces for well accepted browser design paradigms. That way different implementations can share the same interfaces. Obviously we've gotta be careful of what goes in there. -- Brian Sutherland
participants (12)
-
Benji York -
Brian Sutherland -
Christian Zagrodnick -
Dieter Maurer -
Fred Drake -
Marius Gedminas -
Martijn Faassen -
Robert Niederreiter -
Roger Ineichen -
Shane Hathaway -
Stephan Richter -
Tres Seaver