Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thursday 15 April 2004 17:11, Martijn Faassen wrote: Anyway, I guess the tokenizer is fine too, and might even be faster for all I know, just seems an unfortunate duplication of work, plus I checked in importchecker for little reason. :) No, Fred was just a bit faster than me with improving finddeps. I think we definitely should abstract the import search functionality and put it in a lib. The importchecker for example should also look at ZCML to find possible usages of imports. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Sidnei da Silva wrote: On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote: | - The packages in z can be used for more than just Zope | | +2 So, here's an idea: - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*. Great So, what about this: zope.component zope.interfaces (?) zope.configuration zope.testing zope.schema (soon-to-be-dead?) - All move to 'ca.*' Most of this has nothing to do with the component architecture. ca has nothing to do with zope. zope.app.* - Move down to 'zope'. This doesn't solve name-conflict the problem. Or maybe I don't understand what you are proposing. This is pretty rough. Probably there are more stuff that should move to 'ca', and some stuff which should be grouped into packages, so that 'zope' doesn't get excessively broad. I think the depth vs breadth balence we have now is about right. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | So, what about this: | | zope.component | zope.interfaces (?) | zope.configuration | zope.testing | zope.schema (soon-to-be-dead?) | | - All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | ca has nothing to do with zope. So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'? I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2. Maybe you can enumerate what packages are part of the component architecture, and what packages would be used in zope2? I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong. | zope.app.* | | - Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing. See above. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher The most important early product on the way to developing a good product is an imperfect version. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Sidnei da Silva wrote: On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | So, what about this: | | zope.component | zope.interfaces (?) | zope.configuration | zope.testing | zope.schema (soon-to-be-dead?) | | - All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | ca has nothing to do with zope. So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'? From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. The one subpackage that's not usable outside the application server is the app subpackage, zope.app, which *is* the application server. Sub-packages of zope.app are not usable outside of the application server. If there's something in zope.app you want to use elsewhere, let us know and we can talk about abstracting some of it up out of zope.app. I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2. Potentially, all of them. Maybe you can enumerate what packages are part of the component architecture, zope.component and what packages would be used in zope2? All of them, eventually probably including zope.app. I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong. I think you are probably wrong. But we don't know for sure yet. | zope.app.* | | - Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing. See above. I still don't see how having a different package named zope addresses the name conflict with Zope. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote: From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. I've also heard that zope.schema is going away and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Lennart Regebro wrote: From: Sidnei da Silva [EMAIL PROTECTED] - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. 'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of course that means that suddenly the component architecture is called z No, the component architecture is z.component. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Barry Warsaw wrote: On Thu, 2004-04-15 at 09:25, Jim Fulton wrote: From the zope package README.txt: Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. Eactly. Freds work is going to adress this problem. (I'll restrain myself from going into a tirade about how important this is for Python. :) I've also heard that zope.schema is going away I thin it will eventually be merged into zope.interface. and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. Right, maybe But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. We're aware of this problem. That's why we've decoded to make the dependency data explicit (manually created) rather than implicit (automatically created). Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. Probably neither. I doubt that there will ever be a standard Python interface system. I'm not going to hold my breath. Guido argued for having Zope's interfaces be in s subpackage (or have a weird name) specifically to make it easier to add a standard interface package later, assuming that a standard package might not be exactly the same as Zope's. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world We've had colisions in the past. That's why we're being careful now. (BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.) The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z. so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. I think that that's a different discussion. The safest thing to do for now is to continue using a container package. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote: Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal. That's very comforting! I like that it forces developers to be deliberate when adding cross-subpackage dependencies. -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote: Additionally (and Jim and I have discussed this amongst ourselves) I feel strongly that the dependancies should be enforced by tests. Good point. The dependancy tests might need to be separate from unittests because they would probably require an import hook or somesuch. Perhaps a tool like pychecker could be leveraged or extended to provide this service. At a minimum this test would need to be run before packaging a distribution, but ideally would happen more often. I wonder if some kind of doctest could be added to the __init__.py of the package that hooked __import__ and then attempted to import each module in the package, tracking the imports. Then complain about anything not defined in DEPENDENCIES.cfg (and hmm, what to do about standard library imports?). Yeah, maybe some kind of pychecker hook would be better. :/ -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Stephan Richter wrote: On Thursday 15 April 2004 11:39, Casey Duncan wrote: Additionally (and Jim and I have discussed this amongst ourselves) I feel strongly that the dependancies should be enforced by tests. That is, if you introduce and errant dependancy (by adding an import to a new package not in the stdlib or DEPENDANCIES.cfg) that it break a dependancy test. I think this can be easily done using the finddeps.py utility. I think the hard work of finding all the dependencies in the first place is done. Note that Zope can also have dependencies in its ZCML files (which is handled by finddeps.py). Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Fred has fixed that a while ago already (if I read the checkins correctly). :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope3-dev] Re: [Zope-dev] Re: More arguments for z (was Re: Zope and zope)
Stephan Richter wrote: On Thursday 15 April 2004 13:22, Martijn Faassen wrote: Note that for checking dependencies in Python code I still think this tool could be improved by using technology from importchecker.py http://cvs.zope.org/Zope3/utilities/importchecker.py which can use Python's compiler module to lift all imports from source code, which I think is safer than the hand crafted parser approach finddeps.py takes now. If somebody lets me know which API they want implemented for retrieving imports (and use of imports) I could do this lifting work myself. Fred has fixed that a while ago already (if I read the checkins correctly). :-) Well, perhaps I missed something. It changed to use the Python tokenizer, I think, if it wasn't doing this already. It doesn't use the compiler module, as importchecker does Anyway, I guess the tokenizer is fine too, and might even be faster for all I know, just seems an unfortunate duplication of work, plus I checked in importchecker for little reason. :) Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
