Re: [Zope-dev] Re: Zope without Zope
On 17. Nov 2007, at 02:15, Martin Aspeli wrote: I understand the historical reasons behind these dependencies, but I genuinely think we should pick a few libraries that are useful to the outside world (zope.interface, zope.component, zope.configuration, zope.annotation, zope.event come to mind) and work to make these have clean dependencies. +1 and zope.schema. Stefan -- Anything that happens, happens. --Douglas Adams ___ 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 )
Re: [Zope-dev] Re: Zope without Zope
On Nov 16, 2007, at 8:15 PM, Martin Aspeli wrote: ... In any case, I definitely see a case for both. I can't see a good reason why we can't have support for simple XML-based component registration without having to depend on the ZODB and tons of other Zope eggs. You're right. We can. Someone will have to write that. I suspect that starting from the current zcml support, all that's necessary is to strip out permission support. I understand the historical reasons behind these dependencies, but I genuinely think we should pick a few libraries that are useful to the outside world (zope.interface, zope.component, zope.configuration, zope.annotation, zope.event come to mind) and work to make these have clean dependencies. Most or all of the ones you mention already do. zope.component's dependencies are clean as long as you don't try to use the zcml support. zope.annotation is the only one I'm not sure about but I bet it's dependencies are modest. Jim -- Jim Fulton Zope Corporation ___ 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] Re: Zope without Zope
Jim Fulton wrote: I understand the historical reasons behind these dependencies, but I genuinely think we should pick a few libraries that are useful to the outside world (zope.interface, zope.component, zope.configuration, zope.annotation, zope.event come to mind) and work to make these have clean dependencies. Most or all of the ones you mention already do. zope.component's dependencies are clean as long as you don't try to use the zcml support. zope.annotation is the only one I'm not sure about but I bet it's dependencies are modest. zope.component, zope.interface and zope.schema worked well for me. zope.annotation does not work well at all - it's sat here doing zope.app.appsetup as I type this; zope.app.component, zope.app.authentication, zope.app.debug, zope.app.dependable, zope.publisher... I won't go on. I think zope.location which includes zope.security is the culprit. In general, I guess if we have zope.* packages depending on zope.app.* packages, something is wrong. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Re: Zope without Zope
Stephan Richter wrote: On Friday 16 November 2007, Jim Fulton wrote: Something is broken here and it needs to be fixed. Well, the easiest solution would be to remove those misbehaving distributions from the cheeseshop. However, I think we kid ourselves if we think that the cheeseshop will always provide a stable set by default. This would be like saying that all packages from all versions of one Linux distribution are in one repository and nothing will break. It'd work if setuptools supported a 'give me a version that works' feature. You'd just have to specify the working dependencies along with the loose dependencies in setup.py. You'd still have potential problems if you use multiple packages that share a dependency, and the working version they suggest conflicts. It's then up to the end user to break the conflict. Theoretically, as long as you'd follow the loose dependencies and we maintain those well, things would still work. I can even think of a trivial example. Let's say package A works only with Python 2.x and package B works only with Python 3.0a. The supported Python versions are not part of the meta-data of a package. As a naive user, I want to use both, but can't. Heh, Python 3 will cause way more problems than this. We should avoid releasing Python 3 versions for our packages for that reason. If you release them, I'd suggest picking a different name for the egg altogether - that's what is typically done in Linux distributions if there are multiple incompatible versions of a library (GTK 1 and 2, for instance). 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] Re: Zope without Zope
Hi Chris, Then I tried to easy_install zope.security, but this pulled in most of Zope, including the ZODB, ZConfig and zdaemon. That's a real shame - no CA (at least not with ZCML) without having pretty much all of Zope there. :( Yup. Inappropriate dependency chain when you use the cheeseshop. See http://mail.zope.org/pipermail/zope-dev/2007-November/030276.html I was trying to pass -i KGS url to easy_install to use the KGS. Is that not right? Actually, I never got to try it further, because this then died with: Installed /Users/optilude/Development/Pylons/zylons/lib/python2.4/ site-packages/ZConfig-2.5-py2.4.egg error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing=3.5.0a1.dev-r78730 If you're trying to installed these eggs using easy_install against the Cheeseshop, it won't work because the information in the setup.py of some eggs isn't the whole story about required versions of dependencies. Instead, some of version pinning information is stored in buildout.cfg (in a [versions] section) within these eggs. If you use buildout to install them, or use the KGS as the index URL to easy_install it will probably work. See http://mail.zope.org/pipermail/zope-dev/2007-November/030279.html (and actually the rest of that thread) for the whole story. I tried that, so either I'm doing something wrong or it doesn't work. Can someone try to easy_install zope.security against the KGS? In the short term, you should be able to do either of the following: - use buildout to install the eggs - use easy_install --index-url=http://download.zope.org/zope3.4 distribution As far as I know, that's what I did. :-/ The first one will work due to version-pinning statements in the buildout.cfg of dependent eggs. The second one works because it doesn't find the bad distribution of zope.app.publisher that exists on the Cheeseshop that causes the later conflict. You'll still get a bunch of eggs you don't need, but at least they'll get installed. :-/ Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Re: Zope without Zope
Lennart Regebro wrote: On Nov 16, 2007 11:41 AM, Lennart Regebro [EMAIL PROTECTED] wrote: On Nov 16, 2007 3:38 AM, Martin Aspeli [EMAIL PROTECTED] wrote: Help appreciated! Well, I suggest you forget about ZCML and try to use the CA directly from Python. The Pylons people would probably appreciate the lack of XML anyway. :) i'd also recommend this. i've actually been working on a pylons app that uses zope.component, it works like a dream. zope.component brings in a total of 6 eggs, IIRC. if you really want zcml-like separation of config and code, then put your python configuration declarations in a separate module. this not only Just Works(tm), but i think lennart's point about not scaring people away w/ an XML-based config language is a huge one. -r ___ 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] Re: Zope without Zope
Rob Miller wrote: Lennart Regebro wrote: On Nov 16, 2007 11:41 AM, Lennart Regebro [EMAIL PROTECTED] wrote: On Nov 16, 2007 3:38 AM, Martin Aspeli [EMAIL PROTECTED] wrote: Help appreciated! Well, I suggest you forget about ZCML and try to use the CA directly from Python. The Pylons people would probably appreciate the lack of XML anyway. :) i'd also recommend this. i've actually been working on a pylons app that uses zope.component, it works like a dream. zope.component brings in a total of 6 eggs, IIRC. if you really want zcml-like separation of config and code, then put your python configuration declarations in a separate module. this not only Just Works(tm), but i think lennart's point about not scaring people away w/ an XML-based config language is a huge one. Depends on the people. At work, we're using Spring (which, as far as Java goes, is great). The notion of having XML-based configuration gives a lot of wins in certain types of applications - mostly around being able to override deployment type settings in a staging or developer environment. In any case, I definitely see a case for both. I can't see a good reason why we can't have support for simple XML-based component registration without having to depend on the ZODB and tons of other Zope eggs. I understand the historical reasons behind these dependencies, but I genuinely think we should pick a few libraries that are useful to the outside world (zope.interface, zope.component, zope.configuration, zope.annotation, zope.event come to mind) and work to make these have clean dependencies. We don't have to do it all at once, just try to identify where there is a need (to me - using basic CA functions, including externalised configuration). We should also market this, just like Lennart did with his recent blog post (thanks Lennart!) Otherwise, they are not usable outside Zope-the-megaframework, in which case, why are we doing all this eggification and attempting to share the love? :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
