Hi steering group and Dan During update z3c.authenticator and replace the password with the new zope.apssword implementation, I saw that the vocabulary "Passsword Manager Names" is not available in the zope.password package. I think the password package should also provide this vocabulary. Or at least the zope.app.authentication package should not configure that. Do you see any solution to solve that problem that not both package zope.app.authentication and z3c.authenticator configure that utility within the same name (needs the exclude directive for make that working) Regards Roger Ineichen _____________________________ END OF MESSAGE
2009/3/10 Roger Ineichen <dev@projekt01.ch>:
Hi steering group and Dan
During update z3c.authenticator and replace the password with the new zope.apssword implementation, I saw that the vocabulary "Passsword Manager Names" is not available in the zope.password package.
I think the password package should also provide this vocabulary. Or at least the zope.app.authentication package should not configure that.
Do you see any solution to solve that problem that not both package zope.app.authentication and z3c.authenticator configure that utility within the same name (needs the exclude directive for make that working)
This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the "vocabulary" submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that. -- WBR, Dan Korostelev
Dan Korostelev wrote:
This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the "vocabulary" submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that.
That reasoning sounds flawed to me. Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema. Hanno
2009/3/10 Hanno Schlichting <hannosch@hannosch.eu>:
Dan Korostelev wrote:
This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the "vocabulary" submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that.
That reasoning sounds flawed to me.
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary. -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/3/10 Hanno Schlichting <hannosch@hannosch.eu>:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand. What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section. That feels wrong. Either you have a dependency and so have the tests or you don't. I think extras have been created for this kind of use-case of providing an "optional feature" from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead. Hanno
Hi Steering group, Hanno, Dan
Betreff: Re: [Zope-dev] zope.password
Dan Korostelev wrote:
2009/3/10 Hanno Schlichting <hannosch@hannosch.eu>:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand.
What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section.
That feels wrong. Either you have a dependency and so have the tests or you don't.
I think extras have been created for this kind of use-case of providing an "optional feature" from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead.
Hanno, Can you propose something else to solve our problem? The problem is, zope.password offers password manager which get used by zope.app.testing, zope.app.authentication, z3c.authenticator and other packages. zope.app.authentication configures the vocabulary for the password managers in zope.password. That's defently a no go. Write another package for just define and register them is I think also a no go. Probably we should depend zope.password on zope.schema too and configure the vocabulary and managers registry there. Dan, I think we should not be to excessive with the dependency cleanup and stop ourself. It would be nice to use zope.password without the zope.schema package but that's right now no use case for our refactoring. Steering group?
Hanno
_______________________________________________ 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 )
2009/3/10 Roger Ineichen <dev@projekt01.ch>:
Hi Steering group, Hanno, Dan
Betreff: Re: [Zope-dev] zope.password
Dan Korostelev wrote:
2009/3/10 Hanno Schlichting <hannosch@hannosch.eu>:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand.
What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section.
That feels wrong. Either you have a dependency and so have the tests or you don't.
I think extras have been created for this kind of use-case of providing an "optional feature" from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead.
Hanno, Can you propose something else to solve our problem?
The problem is, zope.password offers password manager which get used by zope.app.testing, zope.app.authentication, z3c.authenticator and other packages. zope.app.authentication configures the vocabulary for the password managers in zope.password.
That's defently a no go.
Write another package for just define and register them is I think also a no go.
Probably we should depend zope.password on zope.schema too and configure the vocabulary and managers registry there.
Dan, I think we should not be to excessive with the dependency cleanup and stop ourself. It would be nice to use zope.password without the zope.schema package but that's right now no use case for our refactoring.
I'd like to be able to use zope.password without zope.component for some of my tiny old Pylons-based projects, that's why I'm trying to avoid dependency on it. I believe that repoze guys will also be quite happy, if it didn't pull unneeded (for them) dependency. I'd be fine with an "extra" requirement, but others seem to be against that. :-/ Steering group? ;-) -- WBR, Dan Korostelev
Hi Dan
Betreff: Re: [Zope-dev] zope.password
2009/3/10 Roger Ineichen <dev@projekt01.ch>:
Hi Steering group, Hanno, Dan
Betreff: Re: [Zope-dev] zope.password
Dan Korostelev wrote:
2009/3/10 Hanno Schlichting <hannosch@hannosch.eu>:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand.
What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section.
That feels wrong. Either you have a dependency and so have the tests or you don't.
I think extras have been created for this kind of use-case of providing an "optional feature" from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead.
Hanno, Can you propose something else to solve our problem?
The problem is, zope.password offers password manager which get used by zope.app.testing, zope.app.authentication, z3c.authenticator and other packages. zope.app.authentication configures the vocabulary for the password managers in zope.password.
That's defently a no go.
Write another package for just define and register them is I think also a no go.
Probably we should depend zope.password on zope.schema too and configure the vocabulary and managers registry there.
Dan, I think we should not be to excessive with the dependency cleanup and stop ourself. It would be nice to use zope.password without the zope.schema package but that's right now no use case for our refactoring.
I'd like to be able to use zope.password without zope.component for some of my tiny old Pylons-based projects, that's why I'm trying to avoid dependency on it. I believe that repoze guys will also be quite happy, if it didn't pull unneeded (for them) dependency.
I think that's a valid reason for your use case. But that's a problem for the zope framework ;-)
I'd be fine with an "extra" requirement, but others seem to be against that. :-/
I think we don't have any replacement pattern for extra_requires. The extra_requires where developed for exactly that reason. We should use that pattern till someone will show us a better concept. I also think to add an additional package for register a vocabulary is very ugly. Probably we should think about zope.app.security or something like that and move the password managers and vocabulary to someting like that. Regards Roger Ineichen
On Tuesday 10 March 2009, Dan Korostelev wrote:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I think we have become dependency paranoid. And we embrace package proliferation instead, which in my opinion is equally bad. If you really hate the dependency, make it an extra requires. I know that goes against the latest guidelines as well...*sigh* My big problem here is that we dismiss all solutions but new packages. We want to minimize dependencies and not have extra includes. The only choice left is a separate package. We should, however try to make the number of packages a parameter too. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi Stephan
Betreff: Re: [Zope-dev] zope.password
On Tuesday 10 March 2009, Dan Korostelev wrote:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I think we have become dependency paranoid. And we embrace package proliferation instead, which in my opinion is equally bad. If you really hate the dependency, make it an extra requires. I know that goes against the latest guidelines as well...*sigh*
My big problem here is that we dismiss all solutions but new packages. We want to minimize dependencies and not have extra includes. The only choice left is a separate package. We should, however try to make the number of packages a parameter too.
This is exactly my reaction. It is allways bad to skip existing patterns without to have a better one. Note, there is always a reason for a pattern. We didn't just develop that for fun. I think the steering group should think about what are the consequence if we skip someting and how we can solve the problems which get solved based on patterns they like to skip. Right now it means, skip extra_requires forces us to add more new package and include them in the original package for BBB reason which will add back the same dependency like we tried to skip with extra_requires. But now as a hard depenency. ouch! Regards Roger Ineichen
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Tuesday 10 March 2009, Dan Korostelev wrote:
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's "password.zcml" file, include "zope.password" explicitly and define your own vocabulary.
I think we have become dependency paranoid. And we embrace package proliferation instead, which in my opinion is equally bad. If you really hate the dependency, make it an extra requires. I know that goes against the latest guidelines as well...*sigh*
My big problem here is that we dismiss all solutions but new packages. We want to minimize dependencies and not have extra includes. The only choice left is a separate package. We should, however try to make the number of packages a parameter too.
It seems to me that "extras" are a lot like Gentoo USE flags, except that the infrastructure for USE flags is much more complete. USE flags are an essential feature of Gentoo. Perhaps if the Python packaging chain had similar infrastructure, there would no longer be a reason to avoid extras and we could solve packaging and dependency problems a lot more easily. Here are a few things you can do with USE flags that you can't yet do with extras: - You can enable or disable a USE flag globally (yet override it per-package). If you don't need X-Windows on your server, just add "-X" to /etc/make.conf, and nothing will be built with optional X support. If we had this feature, we would just add "-zope.component" to buildout.cfg and nothing would be installed with optional component architecture support. - Packagers can specify whether a USE flag should be enabled by default. - USE flags can cause whole chunks of code to not be compiled or installed. I would love to be able to specify "-coptimizations" to build a Zope app without any optional C optimizations. (That way, tracebacks would often be more informative.) These days I run both a Gentoo and an Ubuntu box. The Gentoo box has more features, but fewer packages, because Gentoo doesn't have to divide packages to avoid dependencies. My $0.02. Shane
Hanno Schlichting wrote:
Dan Korostelev wrote:
This was done to avoid dependency on zope.schema. However, I also find it very useful to have that vocabulary in zope.password. I think we can add it to the "vocabulary" submodule without adding dependency on zope.schema at egg level, because one who wants to use the vocabulary probably already has zope.schema installed. I'll do that.
That reasoning sounds flawed to me.
Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use "extras" anymore, I think this calls for another package which depends on zope.password and zope.schema.
If zope.schema is imported from directly, it should be declared as a dependency. Regards, Martijn
Hey, If it's more convenient to have the vocabulary available in zope.password, by all means add it there. Regards, Martijn
Hi there, Okay, having read the whole thread, there seem to be two forces pulling on zope.password: * it'd be nice if zope.password had the vocabulary so that you didn't have to include zope.app.authentication anymore just to get it. * it'd be nice if zope.password didn't need any extra dependencies, including zope.component and zope.schema. I think the latter is the least important right now, especially since zope.component and zope.schema are already very foundational libraries. So just add the vocabulary to zope.password if that is the only new dependencies it will pull in as a result. In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. Regards, Martijn
2009/3/11 Martijn Faassen <faassen@startifact.com>:
Hi there,
Okay, having read the whole thread, there seem to be two forces pulling on zope.password:
* it'd be nice if zope.password had the vocabulary so that you didn't have to include zope.app.authentication anymore just to get it.
* it'd be nice if zope.password didn't need any extra dependencies, including zope.component and zope.schema.
I think the latter is the least important right now, especially since zope.component and zope.schema are already very foundational libraries. So just add the vocabulary to zope.password if that is the only new dependencies it will pull in as a result.
I've moved the vocabulary to zope.password again, but I done the "extra" for now, until the final decision will be made.
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action.
Well, as I said before, I wanted to use zope.password in my old Pylons application that only uses zope.interface currently. I don't expect it to be developed in more zope-ish way (though I don't expect it to be developed much in near future :)), so I'd like to avoid these dependencies. -- WBR, Dan Korostelev
Dan Korostelev wrote: [snip]
Well, as I said before, I wanted to use zope.password in my old Pylons application that only uses zope.interface currently. I don't expect it to be developed in more zope-ish way (though I don't expect it to be developed much in near future :)), so I'd like to avoid these dependencies.
Okay, thanks for the elaboration on this. Let's try the extra for now then and see how it goes. Regards, Martijn
On Wednesday 11 March 2009, Martijn Faassen wrote:
I think the latter is the least important right now, especially since zope.component and zope.schema are already very foundational libraries. So just add the vocabulary to zope.password if that is the only new dependencies it will pull in as a result.
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action.
+1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi there, Stephan Richter wrote: [snip]
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action.
+1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well.
I agree with you in the case against extras. It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder. I'm just glad we actually had a quick discussion about this stuff, with some form of conclusion. On creating new packages, I think we're in a phase where we cannot avoid creating new packages for a bit. Before long I hope that this generation of more packages can allow us to seriously weed in the packages in the framework. Zope 3 + ZMI will need a lot more packages for a while, but anything that doesn't need the ZMI (Grok, Zope 2) will hopefully use a lot less. In addition I hope more of our packages will be reusable independently as a result. I hope that some group will start to take care of Zope 3 and perhaps consolidate a lot of ZMI code into one or more zmi.* packages eventually too. Besides the reusability argument and weeding argument for more packages, I'll also note that if the amount of packages in the framework goes up but the total amount of *code* in the framework goes down significantly and each package is easier to understand, I'm happy to see the amount of packages go up. We'll see. We'll make some mistakes, undoubtedly, but at least we're moving again. That is pretty important to me. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hi there,
Stephan Richter wrote: [snip]
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. +1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well.
I agree with you in the case against extras.
It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder.
I'm just glad we actually had a quick discussion about this stuff, with some form of conclusion.
On creating new packages, I think we're in a phase where we cannot avoid creating new packages for a bit. Before long I hope that this generation of more packages can allow us to seriously weed in the packages in the framework. Zope 3 + ZMI will need a lot more packages for a while, but anything that doesn't need the ZMI (Grok, Zope 2) will hopefully use a lot less. In addition I hope more of our packages will be reusable independently as a result.
We should be trying to get all zope.app.* dependencies out of the Zope2 graph ASAP (before 2.12 final would be ideal).
I hope that some group will start to take care of Zope 3 and perhaps consolidate a lot of ZMI code into one or more zmi.* packages eventually too.
Besides the reusability argument and weeding argument for more packages, I'll also note that if the amount of packages in the framework goes up but the total amount of *code* in the framework goes down significantly and each package is easier to understand, I'm happy to see the amount of packages go up.
=lots. Smaller, easier to comprehent packages should be a major goal. 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 iD8DBQFJuC6j+gerLs4ltQ4RArvxAKCTzJFoNUSUmgWVwsuBl9RgMgvEhQCgnaFW tR2pkFQjxHl0Xrt8iaGmAaY= =pVpO -----END PGP SIGNATURE-----
On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote:
Hi there,
Stephan Richter wrote: [snip]
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action.
+1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well.
I agree with you in the case against extras.
It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder.
I remember that at the sprint we used to identify packages which are "always good". E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. In addition this would need documentation as well. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Theune wrote:
On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote:
Hi there,
Stephan Richter wrote: [snip]
In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. +1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well. I agree with you in the case against extras.
It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder.
I remember that at the sprint we used to identify packages which are "always good". E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component.
That woould imply the transitive closure of their dependencies, which would be: - - zope.event - - zope.i18nmessageid - - zope.interface - - zope.component - - zope.schema We would need to finish trimming off the zope.component extras, first. Once done, those pacakges are all essentially "libraries," and could be managed as a "chunk."
In addition this would need documentation as well.
Fleshing out the in-package narrative docs for those packages (or perhaps for the set?) would be pretty valuable, too. 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 iD8DBQFJwNge+gerLs4ltQ4RAtV8AKC0+44VxwGBq4n65uwM+ry4xRQfsQCfbQTQ klc7Xe1goO+nSPfaAflpl48= =2+XJ -----END PGP SIGNATURE-----
Christian Theune wrote:
I remember that at the sprint we used to identify packages which are "always good". E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component.
To whitelist zope.component would be quite interesting. As I recall, there was a time when all packages that depended on zope.component were required to be in the zope.app namespace. I don't object to the idea, though. We're using zope.schema and zope.component almost like language features. Shane
On Wed, 2009-03-18 at 13:07 -0600, Shane Hathaway wrote:
Christian Theune wrote:
I remember that at the sprint we used to identify packages which are "always good". E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component.
To whitelist zope.component would be quite interesting. As I recall, there was a time when all packages that depended on zope.component were required to be in the zope.app namespace.
Interesting, didn't know/remember that.
I don't object to the idea, though. We're using zope.schema and zope.component almost like language features.
Same here. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (8)
-
Christian Theune -
Dan Korostelev -
Hanno Schlichting -
Martijn Faassen -
Roger Ineichen -
Shane Hathaway -
Stephan Richter -
Tres Seaver