Hey All, I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try: [buildout] parts = zopetest [zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2 ...and was rewarded with: Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'. wtf? Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.03.2009 15:47 Uhr, Chris Withers wrote:
Hey All,
I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try:
[buildout] parts = zopetest
[zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2
...and was rewarded with:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
wtf?
Same problem as Dieter had some days ago using easy_install. I spent some time finding the crappy package but failed so far. For now: perform a SVN checkout of the Zope trunk and use this (bootstrap.py + bin/buildout game). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknNPEcACgkQCJIWIbr9KYwK+QCgqlDruBd5nyVahnq03jafn0uf tpwAoKwzsBwb33drQ/RaedrN2eSsnW1X =NuiX -----END PGP SIGNATURE-----
Chris Withers wrote:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
Okay, so I thought I'd be smart and try the following buildout.cfg: [buildout] parts = zopetest versions = versions [versions] zope.component=3.6.0 [zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2 But this still burps: We have the distribution that satisfies 'zope.configuration==3.4.1'. The version, =3.6.0, is not consistent with the requirement, 'zope.component==3.5.1'. While: Installing zopetest. Error: Bad version =3.6.0 Okay, so the 2.12.0.a1 zope2 egg specifies zope.component 3.5.1, fair enough, so lets dig into what wants zope.component 3.6.0... As the original error messages says, it's zope.app.security 3.7.0 that wants zope.component 3.6.0. But wait, zope2 2.12.0.a1 SPECIFIES a hard requirement of zope.app.security 3.6.0. What the hell is zope.app.security 3.7.0 doing being dragged down? Is this a buildout snafu? Jim? cheers, Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.03.2009 16:02 Uhr, Chris Withers wrote:
Chris Withers wrote:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
Okay, so I thought I'd be smart and try the following buildout.cfg:
Stop with your approach right now until we have understood what's going wrong. Working with a SVN checkout from the trunk works (as said). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknNQE8ACgkQCJIWIbr9KYzg3ACgmMwrsKXIyjBjVI8/2r57lYSW ZUMAn2mTm0vVhdM3R17306nABzvssYQw =LZvd -----END PGP SIGNATURE-----
Andreas Jung wrote:
Stop with your approach right now until we have understood what's going wrong. Working with a SVN checkout from the trunk works (as said).
I'm interested in actually solving what's wrong ;-) This feels like buildout doing something wrong, at the very least. It has a hard-nailed version for zope.app.security and appears to be ignoring that... Chris
On Fri, Mar 27, 2009 at 16:11, Chris Withers <chris@simplistix.co.uk> wrote:
Andreas Jung wrote:
Stop with your approach right now until we have understood what's going wrong. Working with a SVN checkout from the trunk works (as said).
I'm interested in actually solving what's wrong ;-)
Chris, go! Two free beer during PyCon if you can figure it out :-) Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.03.2009 16:11 Uhr, Chris Withers wrote:
Andreas Jung wrote:
Stop with your approach right now until we have understood what's going wrong. Working with a SVN checkout from the trunk works (as said).
I'm interested in actually solving what's wrong ;-)
This feels like buildout doing something wrong, at the very least. It has a hard-nailed version for zope.app.security and appears to be ignoring that...
One last hint: you might try using 'pip' (instead of 'easy_install'). 'pip -v' gives you better information about the dependencies pulled in and where (but it does not tell you why - at least not obviously). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknNQqMACgkQCJIWIbr9KYy3EQCg6Qaqzp3rDBev3R8tfY+wzvou dpQAnR0R1Xg7WF/w0xvF75jJe64fQpip =1Dlv -----END PGP SIGNATURE-----
Andreas Jung wrote:
One last hint: you might try using 'pip' (instead of 'easy_install'). 'pip -v' gives you better information about the dependencies pulled in and where (but it does not tell you why - at least not obviously).
Engage brain ;-) I'm not using easy_install, I'm using buildout... (yeah, I know buildout uses easy_install, but...) Chris
On Fri, Mar 27, 2009 at 04:27:31PM -0500, Chris Withers wrote:
Andreas Jung wrote:
One last hint: you might try using 'pip' (instead of 'easy_install'). 'pip -v' gives you better information about the dependencies pulled in and where (but it does not tell you why - at least not obviously).
Engage brain ;-)
I'm not using easy_install, I'm using buildout...
(yeah, I know buildout uses easy_install, but...)
One possibility: try using http://pypi.python.org/pypi/gp.recipe.pip ? -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
I'm not using easy_install, I'm using buildout...
(yeah, I know buildout uses easy_install, but...)
One possibility: try using http://pypi.python.org/pypi/gp.recipe.pip ?
I need to be totally upfront about this: I'm interested in finding out why something that *should* work is broken. I worry that there's something not quite right in buildout that's causing that, and that's something I'd like to fix... I'm NOT interested in working around the problem, specifically by trying out weird'n'whacky recipes... Chris
On Fri, Mar 27, 2009 at 04:34:43PM -0500, Chris Withers wrote:
Paul Winkler wrote:
I'm not using easy_install, I'm using buildout...
(yeah, I know buildout uses easy_install, but...)
One possibility: try using http://pypi.python.org/pypi/gp.recipe.pip ?
I need to be totally upfront about this:
I'm interested in finding out why something that *should* work is broken. I worry that there's something not quite right in buildout that's causing that, and that's something I'd like to fix...
I'm NOT interested in working around the problem, specifically by trying out weird'n'whacky recipes...
Well, yeah. The point of the suggestion was specifically to help you get more info about the dependency chain, since pip is more verbose about that than easy_install is. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
Well, yeah. The point of the suggestion was specifically to help you get more info about the dependency chain, since pip is more verbose about that than easy_install is.
Well, running buildout -vvvvv gives some good clues, a piece of which is this: Getting required 'zope.app.security' required by zope.app.publication 3.5.1. required by zope.app.component 3.6.0. required by zope.app.testing 3.6.0. We have the best distribution that satisfies 'zope.app.security'. Picked: zope.app.security = 3.7.0 Okay, cute, but WHY is 3.7.0 being picked, rather than the 3.6.0 that's nailed down in zope2 2.12.0a1's setup.py?! These: zope.app.publication 3.5.1. zope.app.component 3.6.0. zope.app.testing 3.6.0. ...are all in the 2.12.0a1 setup.py.. ...and none of them specify any version for zope.app.security, so again, I'm left wondering why buildout is picking zope.app.security 3.7.0 in direct contradiction to the 3.6.0 specced in zope2 2.12.0a1's setup.py? cheers, Chris
Chris Withers wrote:
Paul Winkler wrote:
Well, yeah. The point of the suggestion was specifically to help you get more info about the dependency chain, since pip is more verbose about that than easy_install is.
Well, running buildout -vvvvv gives some good clues, a piece of which is this:
Getting required 'zope.app.security' required by zope.app.publication 3.5.1. required by zope.app.component 3.6.0. required by zope.app.testing 3.6.0. We have the best distribution that satisfies 'zope.app.security'. Picked: zope.app.security = 3.7.0
Okay, cute, but WHY is 3.7.0 being picked, rather than the 3.6.0 that's nailed down in zope2 2.12.0a1's setup.py?!
Off the back of this, I changed the buildout.cfg to be the following: [buildout] parts = zopetest versions = versions [versions] zope.app.security=3.6.0 [zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2 ...and we got much further. So, this has gotta be a buildout bug, right? cheers, Chris PS: Even with the above, the next barf is: Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.authentication 3.7.0 requires 'zope.component>=3.6.0'. Interestingly, zope.authentication *isn't* listed in zope2 2.12.0a1's setup.y. I guess it should be?
Previously Chris Withers wrote:
Paul Winkler wrote:
Well, yeah. The point of the suggestion was specifically to help you get more info about the dependency chain, since pip is more verbose about that than easy_install is.
Well, running buildout -vvvvv gives some good clues, a piece of which is this:
Getting required 'zope.app.security' required by zope.app.publication 3.5.1. required by zope.app.component 3.6.0. required by zope.app.testing 3.6.0. We have the best distribution that satisfies 'zope.app.security'. Picked: zope.app.security = 3.7.0
Okay, cute, but WHY is 3.7.0 being picked, rather than the 3.6.0 that's nailed down in zope2 2.12.0a1's setup.py?!
Because buildout is not installing the Zope2 at that point, so it is not using any version pins defined by the Zope2 egg. That is a design flaw in setuptools at the moment: it works package-by-package instead of trying to figure out what the final target working set should look like. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Mar 27, 2009, at 5:27 PM, Chris Withers wrote:
(yeah, I know buildout uses easy_install, but...)
Not in a significant way. (It uses easy_install to build eggs from source distributions, and nothing else. It really should use bdist_egg instead.) Jim -- Jim Fulton Zope Corporation
On Saturday 28 March 2009 06:11:30 Chris Withers wrote:
Andreas Jung wrote:
Stop with your approach right now until we have understood what's going wrong. Working with a SVN checkout from the trunk works (as said).
I'm interested in actually solving what's wrong ;-)
This feels like buildout doing something wrong, at the very least. It has a hard-nailed version for zope.app.security and appears to be ignoring that...
I don't think zope.app.security is nailed down in your buildout.cfg, because it is listed in extras_require in setup.py, so the version specification is not taken into account, if you specify just "zope2". In fact, this works well: [buildout] parts = zopetest [zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2[zope_app] I cannot say if this is a bug, since I don't know how zc.buildout is supposed to deal with versions for extras. Regards, YO -- Yoshinori Okuji, Nexedi KK President Nexedi: Consulting and Development of Free / Open Source Software http://www.nexedi.co.jp/ ERP5: Full Featured High End Open Source ERP http://www.erp5.com/ ERP5 Wiki: Developer Zone for ERP5 Community http://www.erp5.org/
Chris Withers wrote at 2009-3-27 16:02 -0500:
...
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
Okay, so I thought I'd be smart and try the following buildout.cfg: ... What the hell is zope.app.security 3.7.0 doing being dragged down? Is this a buildout snafu? Jim?
I fear we will have to learn to live with version conflicts until we are ready to pin each and every version used, either in the buildout itself or via a KGS (Known Good Set index). If we let "buildout/setuptools" decide which version to use, there is a good chance that it gets it wrong. The problem would be far smaller if "setuptools" (yes, this is the major component to blame in this case, not "buildout") would first construct the complete dependency graph and then try to search a global solution. Unfortunately, "setuptools" resolves dependancies incrementally (not globally): when it has to handle a dependency, it tries to find a distribution satisfying the requirements taking into account the distributions it already has -- but not the dependency requirements it will also have to satisfy in a short time. This way, it may take a distribution that after a short while will conflict with another dependancy requirement. Your observation above might (other chains are possible) result from: Some dependency specifies: "zope.component==3.5.1". Later some dependancy specifies: "zope.app.security" "setuptools" looks what distribution it can choose. Lacking a more specific prescription, it uses the newest one "zope.app.security==3.7.0". Later, it tries to resolve the dependencies of "zope.app.security==3.7.0" and finds "zope.component==3.6.0". Conflict! To avoid the conflict, "setuptools" would need to backtrack and revise its distribution decision for "zope.app.security" or alternatively first build the complete dependency graph and search a global solution. However, finding such a global solution requires a complex algorithm at least when efficiency is important (which probably is the case as the dependency graphs for larger applications will be huge). Thus: I appreaciate much your wish to solve this problem but expect that it will be quite complex. -- Dieter
On Mar 29, 2009, at 3:28 AM, Dieter Maurer wrote:
Chris Withers wrote at 2009-3-27 16:02 -0500:
...
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
Okay, so I thought I'd be smart and try the following buildout.cfg: ... What the hell is zope.app.security 3.7.0 doing being dragged down? Is this a buildout snafu? Jim?
I fear we will have to learn to live with version conflicts until we are ready to pin each and every version used, either in the buildout itself or via a KGS (Known Good Set index).
If we let "buildout/setuptools" decide which version to use, there is a good chance that it gets it wrong.
The problem would be far smaller if "setuptools" (yes, this is the major component to blame in this case, not "buildout") would first construct the complete dependency graph and then try to search a global solution. Unfortunately, "setuptools" resolves dependancies incrementally (not globally): when it has to handle a dependency, it tries to find a distribution satisfying the requirements taking into account the distributions it already has -- but not the dependency requirements it will also have to satisfy in a short time. This way, it may take a distribution that after a short while will conflict with another dependancy requirement.
Your observation above might (other chains are possible) result from:
Some dependency specifies: "zope.component==3.5.1".
Later some dependancy specifies: "zope.app.security" "setuptools" looks what distribution it can choose. Lacking a more specific prescription, it uses the newest one "zope.app.security==3.7.0".
Later, it tries to resolve the dependencies of "zope.app.security==3.7.0" and finds "zope.component==3.6.0". Conflict!
To avoid the conflict, "setuptools" would need to backtrack and revise its distribution decision for "zope.app.security" or alternatively first build the complete dependency graph and search a global solution.
However, finding such a global solution requires a complex algorithm at least when efficiency is important (which probably is the case as the dependency graphs for larger applications will be huge).
I think that's a good summary of the issue.
Thus: I appreaciate much your wish to solve this problem but expect that it will be quite complex.
I still think it's worth trying. I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this? Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.03.2009 10:47 Uhr, Jim Fulton wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Why would that be a functionality of zc.buildout? I think this belongs into a lower layer like setuptools (or whatever is coming after it). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknPmPkACgkQCJIWIbr9KYyBHwCgxnfEWUN5TrrMdWvVZHrj4wMm A3MAn1HKSB8QDqXx69wP90sQzqLkmLyb =rUoF -----END PGP SIGNATURE-----
Andreas Jung wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Why would that be a functionality of zc.buildout? I think this belongs into a lower layer like setuptools (or whatever is coming after it).
I agree. If you're proposing fixing it in buildout because getting changes made to setuptools and then getting a release of setuptools made is damned near impossible, then that's sad state of affairs for the whole python community :-( What progress was made at the language summit wrt to getting setuptools to a place where it's more than just Phil Eby who can actually do stuff to it? Chris
Previously Chris Withers wrote:
If you're proposing fixing it in buildout because getting changes made to setuptools and then getting a release of setuptools made is damned near impossible, then that's sad state of affairs for the whole python community :-(
You can compare this with dpkg and apt on Debian and Ubuntu systems: dpkg is the lower level install that installs one or more packages. It only checks if the packages you install break any package conflicts and if their dependencies are met. It is simpler than easy_install: it will not look for or download packages itself. Python does not have a such a low level tool - I think it would be useful to factor that out of setuptools into a separate package. Apt is the higher level tool: you give it a list of places where it can find packages (similar to pypi indices, except it does not have a download url concept (which tends to only hurt you anyway) and it figures out what should be done to install a set of packages without violating any constraints. Once it knows how to do this it downloads the packages and calls dpkg to do the actuall installation. I think it makes sense to have a similar approach in python: have a pure installation tool (a subset of easy_install) as well as higher level tools such as zc.buildout which have all the logic necessary to find packages to install and figure out a strategy to get to a target working set. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Mar 29, 2009, at 4:10 PM, Wichert Akkerman wrote: ...
You can compare this with dpkg and apt on Debian and Ubuntu systems: dpkg is the lower level install that installs one or more packages. It only checks if the packages you install break any package conflicts and if their dependencies are met. It is simpler than easy_install: it will not look for or download packages itself. Python does not have a such a low level tool
Yes it does, the setup install command. Jim -- Jim Fulton Zope Corporation
On 3/30/09 4:04 PM, Jim Fulton wrote:
On Mar 29, 2009, at 4:10 PM, Wichert Akkerman wrote: ...
You can compare this with dpkg and apt on Debian and Ubuntu systems: dpkg is the lower level install that installs one or more packages. It only checks if the packages you install break any package conflicts and if their dependencies are met. It is simpler than easy_install: it will not look for or download packages itself. Python does not have a such a low level tool
Yes it does, the setup install command.
That's not quite the same. If you give someone a .egg, .zip or a .tar.gz file they can't install it with a single command. For an egg you will need easy_install, for the other two it is a two step process of unpacking and calling setup.py. Wichert.
On Mar 29, 2009, at 11:51 AM, Andreas Jung wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29.03.2009 10:47 Uhr, Jim Fulton wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Why would that be a functionality of zc.buildout? I think this belongs into a lower layer like setuptools (or whatever is coming after it).
Two reasons: 1. It will be easier to try things out in buildout because we have more control and can release code more quickly and easily, 2. Backtracking is more practical in buildout than with easy_install. easy_install (not sure about pip) does conflict detection/resolution at run time, whereas buildout does it at build time. Slow conflict resolution is a lot more practical when you don't do it every time you start a script. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote at 2009-3-29 12:02 -0400:
... 2. Backtracking is more practical in buildout than with easy_install. easy_install (not sure about pip) does conflict detection/resolution at run time, whereas buildout does it at build time. Slow conflict resolution is a lot more practical when you don't do it every time you start a script.
Are you sure? I think "setuptools" usually only searches for distributions during installation time. Runtime distribution searching is restricted to the "require" call and relevant only for multi version eggs. -- Dieter
On Mar 29, 2009, at 2:35 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2009-3-29 12:02 -0400:
... 2. Backtracking is more practical in buildout than with easy_install. easy_install (not sure about pip) does conflict detection/resolution at run time, whereas buildout does it at build time. Slow conflict resolution is a lot more practical when you don't do it every time you start a script.
Are you sure?
Yes.
I think "setuptools" usually only searches for distributions during installation time. Runtime distribution searching is restricted to the "require" call and relevant only for multi version eggs.
Right, and in that context, you can get exactly the same problem. In addition, without multiple-version installs, you can have the situation that an install causes the dependencies of a previous install to be broken. Jim -- Jim Fulton Zope Corporation
On Sun, Mar 29, 2009 at 11:47:14AM -0400, Jim Fulton wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Ian's Pip tool tries to download everything and work out the complete graph before doing any installation; I've no idea if any of that work could be ported to buildout, but it might be worth a look? https://svn.openplans.org/svn/pip/ (If you guys are both still at Pycon, might be worth a face-to-face chat...) -- Paul Winkler http://www.slinkp.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.03.2009 11:08 Uhr, Paul Winkler wrote:
On Sun, Mar 29, 2009 at 11:47:14AM -0400, Jim Fulton wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Ian's Pip tool tries to download everything and work out the complete graph before doing any installation; I've no idea if any of that work could be ported to buildout, but it might be worth a look? https://svn.openplans.org/svn/pip/
(If you guys are both still at Pycon, might be worth a face-to-face chat...)
We resolved parts of the problem at PyCon yesterday but we need to follow the Zope 3 approach and provide dedicated index page with links to the pinned packages for use with easy_install. - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknQ7vsACgkQCJIWIbr9KYz0IgCgwfy5K/r/wNYZnr9TMEaCr0V3 RQwAn0lQER/OFLnTApOtF1E85+6UcKrw =AuCI -----END PGP SIGNATURE-----
On Mar 30, 2009, at 12:08 PM, Paul Winkler wrote:
On Sun, Mar 29, 2009 at 11:47:14AM -0400, Jim Fulton wrote:
I think an implementation of a better dependency resolution strategy in buildout would be a good place to start. I think some limited backtracking could go a long way. Anyone interested in working on this?
Ian's Pip tool tries to download everything and work out the complete graph before doing any installation; I've no idea if any of that work could be ported to buildout, but it might be worth a look? https://svn.openplans.org/svn/pip/
But this is about determining the complete graph. Jim -- Jim Fulton Zope Corporation
On Mon, Mar 30, 2009 at 12:29:16PM -0400, Jim Fulton wrote:
On Mar 30, 2009, at 12:08 PM, Paul Winkler wrote:
Ian's Pip tool tries to download everything and work out the complete graph before doing any installation; I've no idea if any of that work could be ported to buildout, but it might be worth a look? https://svn.openplans.org/svn/pip/
But this is about determining the complete graph.
I don't understand. What did I say that wasn't relevant to that? -- Paul Winkler http://www.slinkp.com
On Mar 30, 2009, at 1:50 PM, Paul Winkler wrote:
On Mon, Mar 30, 2009 at 12:29:16PM -0400, Jim Fulton wrote:
On Mar 30, 2009, at 12:08 PM, Paul Winkler wrote:
Ian's Pip tool tries to download everything and work out the complete graph before doing any installation; I've no idea if any of that work could be ported to buildout, but it might be worth a look? https://svn.openplans.org/svn/pip/
But this is about determining the complete graph.
I don't understand. What did I say that wasn't relevant to that?
Pip doesn't solve the problem because the problem occurs when trying to determine the complete graph in the first place. Jim -- Jim Fulton Zope Corporation
On Mar 27, 2009, at 4:47 PM, Chris Withers wrote:
Hey All,
I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try:
[buildout] parts = zopetest
[zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2
...and was rewarded with:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
wtf?
Try running buildout in verbose mode (-v). It will tell you why it added zope.component 3.5.1. Jim -- Jim Fulton Zope Corporation
Hi, had the same issue tonight. I'm using attached versions.cfg for now. That works quite well for me. Cheers, Tobias [buildout] versions = versions [versions] Acquisition = 2.12.0a1 DateTime = 2.11.2 ExtensionClass = 2.11.1 Persistence = 2.11.1 tempstorage = 2.11.1 zLOG = 2.11.1 ClientForm = 0.2.10 RestrictedPython = 3.5.0 ZConfig = 2.6.1 ZODB3 = 3.9.0a11 docutils = 0.5 jquery.javascript = 1.0.0 jquery.layer = 1.0.0 lxml = 2.2beta4 mechanize = 0.1.11 pytz = 2009a setuptools = 0.6c9 transaction = 1.0a1 z3c.coverage = 1.1.2 z3c.csvvocabulary = 1.0.0 z3c.etestbrowser = 1.2.1 z3c.form = 1.9.0 z3c.formdemo = 1.5.3 z3c.formjs = 0.4.1 z3c.formjsdemo = 0.3.1 z3c.formui = 1.4.2 z3c.i18n = 0.1.1 z3c.layer.minimal = 1.0.1 z3c.layer.pagelet = 1.0.1 z3c.layer.ready2go = 0.5.1 z3c.layer.trusted = 1.0.1 z3c.macro = 1.1.0 z3c.macroviewlet = 1.0.0 z3c.menu.ready2go = 0.5.1 z3c.menu.simple = 0.5.1 z3c.optionstorage = 1.0.4 z3c.pagelet = 1.0.3 z3c.rml = 0.7.3 z3c.schema = 0.6.0 z3c.skin.pagelet = 1.0.2 z3c.template = 1.2.0 z3c.testing = 0.3.0 z3c.traverser = 0.2.4 z3c.viewtemplate = 0.4.0 z3c.zrtresource = 1.1.0 zc.buildout = 1.2.0 zc.catalog = 1.4.1 zc.datetimewidget = 0.6.1 zc.i18n = 0.6.1 zc.lockfile = 1.0 zc.recipe.egg = 1.1.0 zc.recipe.filestorage = 1.0.1 zc.recipe.testrunner = 1.1.0 zc.resourcelibrary = 1.0.2 zc.table = 0.7.0 zc.zope3recipes = 0.7.0 zdaemon = 2.0.2 zodbcode = 3.4.0 zope.annotation = 3.4.1 zope.app.apidoc = 3.6.1 zope.app.applicationcontrol = 3.4.3 zope.app.appsetup = 3.9.0 zope.app.authentication = 3.5.0a2 zope.app.basicskin = 3.4.0 zope.app.boston = 3.4.0 zope.app.broken = 3.5.0 zope.app.cache = 3.5.0 zope.app.catalog = 3.8.0 zope.app.component = 3.6.0 zope.app.container = 3.7.0 zope.app.content = 3.4.0 zope.app.dav = 3.5.0 zope.app.debug = 3.4.1 zope.app.debugskin = 3.4.0 zope.app.dependable = 3.4.0 zope.app.dtmlpage = 3.5.0 zope.app.error = 3.5.2 zope.app.exception = 3.4.2 zope.app.externaleditor = 3.5.0 zope.app.file = 3.5.0 zope.app.folder = 3.5.0 zope.app.form = 3.7.1 zope.app.ftp = 3.5.0 zope.app.generations = 3.4.2 zope.app.homefolder = 3.5.0 zope.app.http = 3.5.0 zope.app.i18n = 3.5.0 zope.app.i18nfile = 3.4.1 zope.app.interface = 3.4.0 zope.app.interpreter = 3.4.0 zope.app.intid = 3.7.0 zope.app.layers = 3.4.0 zope.app.locales = 3.5.1 zope.app.locking = 3.5.0 zope.app.module = 3.5.0 zope.app.onlinehelp = 3.5.0 zope.app.pagetemplate = 3.5.0 zope.app.pluggableauth = 3.4.0 zope.app.preference = 3.6.0 zope.app.preview = 3.4.0 zope.app.principalannotation = 3.5.0 zope.app.publication = 3.5.1 zope.app.publisher = 3.6.0 zope.app.pythonpage = 3.5.0 zope.app.renderer = 3.5.0 zope.app.rotterdam = 3.5.0 zope.app.schema = 3.5.0 zope.app.security = 3.6.0 zope.app.securitypolicy = 3.5.1 zope.app.server = 3.4.2 zope.app.session = 3.6.0 zope.app.skins = 3.4.0 zope.app.sqlscript = 3.5.0 zope.app.testing = 3.6.0 zope.app.traversing = 3.4.0 zope.app.tree = 3.6.0 zope.app.twisted = 3.4.2 zope.app.undo = 3.5.0 zope.app.wfmc = 0.1.2 zope.app.workflow = 3.5.0 zope.app.wsgi = 3.4.1 zope.app.xmlrpcintrospection = 3.5.0 zope.app.zapi = 3.4.0 zope.app.zcmlfiles = 3.5.2 zope.app.zopeappgenerations = 3.4.0 zope.app.zptpage = 3.5.0 zope.broken = 3.5.0 zope.browser = 0.5.0 zope.cachedescriptors = 3.4.1 zope.catalog = 3.8.0 zope.component = 3.5.1 zope.configuration = 3.4.1 zope.container = 3.7.1 zope.contentprovider = 3.4.0 zope.contenttype = 3.4.1 zope.copy = 3.5.0 zope.copypastemove = 3.5.1 zope.datetime = 3.4.0 zope.decorator = 3.4.0 zope.deferredimport = 3.5.0 zope.deprecation = 3.4.0 zope.documenttemplate = 3.4.2 zope.dottedname = 3.4.5 zope.dublincore = 3.4.2 zope.error = 3.6.0 zope.event = 3.4.0 zope.exceptions = 3.5.2 zope.file = 0.4.0 zope.filerepresentation = 3.5.0 zope.formlib = 3.5.2 zope.hookable = 3.4.0 zope.html = 1.1.0 zope.i18n = 3.6.0 zope.i18nmessageid = 3.4.3 zope.index = 3.5.1 zope.interface = 3.5.0 zope.intid = 3.7.0 zope.keyreference = 3.6.1 zope.lifecycleevent = 3.5.0 zope.location = 3.5.2 zope.mimetype = 0.3.0 zope.minmax = 1.1.0 zope.modulealias = 3.4.0 zope.pagetemplate = 3.4.1 zope.proxy = 3.5.0 zope.publisher = 3.5.5 zope.rdb = 3.5.0 zope.schema = 3.5.2 zope.security = 3.6.0 zope.securitypolicy = 3.5.0 zope.sendmail = 3.5.1 zope.sequencesort = 3.4.0 zope.server = 3.5.0 zope.session = 3.8.1 zope.site = 3.6.0 zope.size = 3.4.0 zope.structuredtext = 3.4.0 zope.tal = 3.5.0 zope.tales = 3.4.0 zope.testbrowser = 3.6.0a2 zope.testing = 3.7.1 zope.testrecorder = 0.3.0 zope.traversing = 3.5.2 zope.ucol = 1.0.2 zope.viewlet = 3.5.0 zope.wfmc = 3.4.0 zope.xmlpickle = 3.4.0 On 27.03.2009, at 21:47, Chris Withers wrote:
Hey All,
I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try:
[buildout] parts = zopetest
[zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2
...and was rewarded with:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
wtf?
Chris _______________________________________________ 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 )
On 28.03.2009, at 00:30, Chris Withers wrote:
Tobias Rodäbel wrote:
Hi,
had the same issue tonight. I'm using attached versions.cfg for now. That works quite well for me.
Which issue is this supposed to help with?
Using zc.buildout. This is my buildut.cfg: [buildout] parts = zope zopepy extends = versions.cfg unzip = true [zope] recipe = zc.recipe.egg:scripts eggs = Zope2 [zopepy] recipe = zc.recipe.egg eggs = Zope2 interpreter = zopepy scripts = zopepy
Tobias Rodäbel wrote:
On 28.03.2009, at 00:30, Chris Withers wrote:
Tobias Rodäbel wrote:
Hi,
had the same issue tonight. I'm using attached versions.cfg for now. That works quite well for me. Which issue is this supposed to help with?
Using zc.buildout.
There are currently two seperate issue with specifying zope2 as an egg in a buildout.cfg. Which of these two issues is your solution designed to address? Chris
On 28.03.2009, at 00:36, Chris Withers wrote:
There are currently two seperate issue with specifying zope2 as an egg in a buildout.cfg.
Which of these two issues is your solution designed to address?
My versions.cfg resolved all version conflicts mentioned within this thread.
Tobias Rodäbel wrote:
My versions.cfg resolved all version conflicts mentioned within this thread.
Cool, I'll bear it in mind, but right now I want to try and actually fix things so they work like they should :-) cheers, Chris
Tobias Rodäbel wrote:
[zope] recipe = zc.recipe.egg:scripts eggs = Zope2
So, this gives you mkzopeinstance, right? (I don't think you need the :scripts It "worked", as in no errors, but when I tried mkzopeinstance, it generated an instance, but that instance didn't work: $ bin/runzope Traceback (most recent call last): File "/Zope2-2.12.0.a1-py2.5-macosx-10.3-i386.egg/Zope2/Startup/run.py", line 56, in <module> run() File "Zope2-2.12.0.a1-py2.5-macosx-10.3-i386.egg/Zope2/Startup/run.py", line 17, in run import Zope2.Startup ImportError: No module named Zope2.Startup How did you get this working? cheers, Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.03.2009 15:47 Uhr, Chris Withers wrote:
Hey All,
I'm trying to get Zope 2.12 working with buildout, in the absence of docs, I thought I'd try:
[buildout] parts = zopetest
[zopetest] recipe = zc.recipe.egg interpreter = py eggs = zope2
...and was rewarded with:
Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
The issue is caused (or at least related) due to the separation of packages in install_requires and extra_requires within the setup.py of the Zope 2 package..I will check this with Hanno during Pycon. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknOGGwACgkQCJIWIbr9KYw1wQCfbpiOapDE7+v2t9pG4bmcjdDe ixAAn0RgxcXumu4o8kxeuzZeR951G8ac =3f6F -----END PGP SIGNATURE-----
participants (8)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Jim Fulton -
Paul Winkler -
Tobias Rodäbel -
Wichert Akkerman -
Yoshinori Okuji