Hi all, For fun, I just tried to make use of adapters and utilities, registered with ZCML, in a Pylons application. I installed Pylons in a virtualenv, and easy_installed zope.component and zope.interface using the KGS index for 3.4. I used zope.configuration (also installed) to load a site.zcml, which currently just has: <configure xmlns="http://namespaces.zope.org/zope"> <include package="zope.component" file="meta.zcml" /> </configure> That doesn't work - it complains about not finding zope.security.zcml. 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. :( 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 Are the Zope eggs ready for prime time? Maybe I should be doing it differently? I'm curious about how to go about this, since it seems like an incredibly useful thing to be able to do: Make use of the CA in a non-Zope Python application. :) Help appreciated! Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Nov 15, 2007, at 9:38 PM, Martin Aspeli wrote:
Hi all,
For fun, I just tried to make use of adapters and utilities, registered with ZCML, in a Pylons application.
I installed Pylons in a virtualenv, and easy_installed zope.component and zope.interface using the KGS index for 3.4. I used zope.configuration (also installed) to load a site.zcml, which currently just has:
<configure xmlns="http://namespaces.zope.org/zope"> <include package="zope.component" file="meta.zcml" /> </configure>
That doesn't work - it complains about not finding zope.security.zcml.
No idea why this happens, sorry.
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 .
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.
Are the Zope eggs ready for prime time?
Not quite. I've created a bot process which attempts to easy_install every distribution having to do with 'zope' from the cheeseshop into a clean virtualenv every few days. I'm hoping this, along with regular prodding from folks like you, will keep us on the right track going forward. See http://mail.zope.org/pipermail/zope-dev/2007-November/030271.html to see an example of the result of the bot. Currently we're still quite broken for people trying to easy_install most zope-related eggs other than zope.interface, zope.component, and ZODB from the Cheeseshop. I asked for help fixing this the other day by asking if someone would remove a "bad" release from the Cheeseshop (I don't have the rights to do that) or by making new releases of eggs which pin versions in setup.py rather than in buildout.cfg (I don't feel qualified to do that, as I know little about the actual software and what impact that would have on people relying on the older version). No one has done it yet, though, I suppose. In the meantime, I've fixed one package (zope.tal) to remove inappropriate dependencies, but a new release hasn't yet been made from the changes I checked in. Once it is, and it's been uploaded to the cheeseshop, you'll be able to install zope.pagetemplate without also getting ZODB and 74 other eggs. ;-) But I'm sure other packages need to get fixed too (in particular, zope.i18n, where things really go pear-shaped).
Maybe I should be doing it differently?
Please don't! Just complain loudly. ;-)
I'm curious about how to go about this, since it seems like an incredibly useful thing to be able to do: Make use of the CA in a non-Zope Python application. :)
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> 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. - C
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
On Nov 16, 2007 3:38 AM, Martin Aspeli <optilude@gmx.net> 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. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
On Nov 16, 2007 11:41 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Nov 16, 2007 3:38 AM, Martin Aspeli <optilude@gmx.net> 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. :)
In fact, I decided to write up my failed EuroPython lightning talk into a blog post about the subject: http://regebro.wordpress.com/2007/11/16/a-python-component-architecture/ And Baiju Ms ZCA book could be helpful too: http://www.muthukadan.net/docs/zca.html -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Nov 16, 2007 11:41 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Nov 16, 2007 3:38 AM, Martin Aspeli <optilude@gmx.net> 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. :)
In fact, I decided to write up my failed EuroPython lightning talk into a blog post about the subject: http://regebro.wordpress.com/2007/11/16/a-python-component-architecture/
I assume it's "failed" because "easy_install zope.component" doesn't work? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Nov 16, 2007 12:49 PM, Chris Withers <chris@simplistix.co.uk> wrote:
I assume it's "failed" because "easy_install zope.component" doesn't work?
No, that worked. It failed because I had 5 minutes, but it took 6. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Nov 16, 2007 11:41 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Nov 16, 2007 3:38 AM, Martin Aspeli <optilude@gmx.net> 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
Rob Miller wrote:
Lennart Regebro wrote:
On Nov 16, 2007 11:41 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Nov 16, 2007 3:38 AM, Martin Aspeli <optilude@gmx.net> 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
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
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
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
On Nov 15, 2007, at 9:38 PM, Martin Aspeli wrote:
Hi all,
For fun, I just tried to make use of adapters and utilities, registered with ZCML, in a Pylons application.
I installed Pylons in a virtualenv, and easy_installed zope.component and zope.interface using the KGS index for 3.4. I used zope.configuration (also installed) to load a site.zcml, which currently just has:
<configure xmlns="http://namespaces.zope.org/zope"> <include package="zope.component" file="meta.zcml" /> </configure>
That doesn't work - it complains about not finding zope.security.zcml.
That's because the zope.component.zcml supports specifying permissions on components. The zcml support never should have been added to zope.component. This also illustrates the false promise of extras. The package has zcml support which you expected to be able to use. After all, it is there. To use zcml, you have to specify the zcml extra. This brings the rest of zope with it. I added the extras myself, despite my dislike of extras, because it was the only way to make zope.component usable without the rest of Zope and without major refactoring and backward incompatibility.
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. :(
But you can use the CA without zcml without the rest of Zope. This should not be under appreciated. I also think extras are a farce. This should not be under appreciated either IMO.
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
Are the Zope eggs ready for prime time? Maybe I should be doing it differently?
Some of them are and some aren't. zope.component will work with just a few packages if you don't use the zcml or persistence support.
I'm curious about how to go about this, since it seems like an incredibly useful thing to be able to do: Make use of the CA in a non-Zope Python application. :)
You can. You just can't use it's zcml support -- which is highly zope specific. Note that there could conceivably be other zcml support that isn't zope specific, but the zcml support in zope.component was moved from zope.app where it really should have stayed. Jim -- Jim Fulton Zope Corporation
On Thursday 15 November 2007, Martin Aspeli wrote:
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. :(
Actually, I never got to try it further, because this then died with:
Installed /Users/optilude/Development/Pylons/zylons/lib/python2.4/site-packages/ZConf ig-2.5-py2.4.egg error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing>=3.5.0a1.dev-r78730
Are the Zope eggs ready for prime time? Maybe I should be doing it differently?
You need to specify the KGS for all downloads, then you would not have gotten the conflict. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Nov 16, 2007 2:07 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
On Thursday 15 November 2007, Martin Aspeli wrote:
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. :(
Actually, I never got to try it further, because this then died with:
Installed /Users/optilude/Development/Pylons/zylons/lib/python2.4/site-packages/ZConf ig-2.5-py2.4.egg error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing>=3.5.0a1.dev-r78730
Are the Zope eggs ready for prime time? Maybe I should be doing it differently?
You need to specify the KGS for all downloads, then you would not have gotten the conflict.
I may have screwed it up (it was late), but I used -i <kgs_url> for each invocation of easy_install. Martin
On Nov 16, 2007, at 9:14 AM, Martin Aspeli wrote:
On Nov 16, 2007 2:07 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu
wrote: On Thursday 15 November 2007, Martin Aspeli wrote:
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. :(
Actually, I never got to try it further, because this then died with:
Installed /Users/optilude/Development/Pylons/zylons/lib/python2.4/site- packages/ZConf ig-2.5-py2.4.egg error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing>=3.5.0a1.dev-r78730
Are the Zope eggs ready for prime time? Maybe I should be doing it differently?
You need to specify the KGS for all downloads, then you would not have gotten the conflict.
I may have screwed it up (it was late), but I used -i <kgs_url> for each invocation of easy_install.
Unless there's some failure mode I haven't seen with the same symptom, somehow your easy_install process managed to find a distribution of zope.app.publisher 3.5.0a2 (which only exists AFAIK on the cheeseshop) that has a dependency on zope.traversing>=3.5.0a1.dev-r78730 instead of zope.app.publisher 3.4.1, which does not. I just tried to do "bin/easy_install --index-url=http://download.zope.org/zope3.4 zope.security" in a clean virtualenv and it worked for me, so I suspect you might have missed typing the --index-url once. You might just blow everything away and try it again. - C
On Nov 16, 2007, at 9:07 AM, Stephan Richter wrote:
On Thursday 15 November 2007, Martin Aspeli wrote:
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. :(
Actually, I never got to try it further, because this then died with:
Installed /Users/optilude/Development/Pylons/zylons/lib/python2.4/site- packages/ZConf ig-2.5-py2.4.egg error: Installed distribution zope.traversing 3.4.0 conflicts with requirement zope.traversing>=3.5.0a1.dev-r78730
Are the Zope eggs ready for prime time? Maybe I should be doing it differently?
You need to specify the KGS for all downloads, then you would not have gotten the conflict.
Stephan, the KGS is great, but it isn't the answer to this situation. Unless we stop uploading packages to the cheeseshop, packages there have to work with the cheeseshop. Pylons users aren't going to switch to a different index just to use zope.component. (Fortunately, they don't need to.) Something is broken here and it needs to be fixed. Jim -- Jim Fulton Zope Corporation
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. 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. Since I do not have time to think of another example involving only Python 2.x right now, I leave it as an exercise to the reader to think of one. ;-) (Oh, did I hate those sentences in my Physics texts!) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
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
participants (9)
-
Chris McDonough -
Chris Withers -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Rob Miller -
Stefan H. Holek -
Stephan Richter