Changes: http://pypi.python.org/pypi/zc.buildout/2.0.0b1#b1-2013-01-21 If problems aren't discovered first, I plan to make the final release next weekend. To install the new release, download: http://downloads.buildout.org/2/bootstrap.py if you haven't already. (It hasn't changed since 2.0.0a6.) Then bootstrap projects with: python bootstrap.py -t Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
Op 21-01-13 13:31, Jim Fulton schreef:
Changes:
http://pypi.python.org/pypi/zc.buildout/2.0.0b1#b1-2013-01-21
If problems aren't discovered first, I plan to make the final release next weekend.
To install the new release, download:
http://downloads.buildout.org/2/bootstrap.py
if you haven't already. (It hasn't changed since 2.0.0a6.)
Then bootstrap projects with:
python bootstrap.py -t
Jim
Works fine in my standard customer buildout. There are a few problems with extensions I use, but they probably need to be fixed in those extensions. If I use the mr.developer extension, "bin/buildout buildout:parts=ipzope" works, but not when you spell it without 'buildout:'. mr.developer seems to work fine with zc.buildout 2.0.0b1, just not for this feature. This is the traceback: $ bin/buildout parts=ipzope While: Installing. Loading extensions. An internal error occured due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.7.egg/zc/buildout/buildout.py", line 1752, in main getattr(buildout, command)(args) File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.7.egg/zc/buildout/buildout.py", line 439, in install self._load_extensions() File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.7.egg/zc/buildout/buildout.py", line 970, in _load_extensions ep.load()(self) File "/Users/mauritsvanrees/shared-eggs/mr.developer-1.21-py2.7.egg/mr/developer/extension.py", line 246, in extension return Extension(buildout)() File "/Users/mauritsvanrees/shared-eggs/mr.developer-1.21-py2.7.egg/mr/developer/extension.py", line 242, in __call__ config.save() File "/Users/mauritsvanrees/shared-eggs/mr.developer-1.21-py2.7.egg/mr/developer/common.py", line 402, in save options, settings, args = parse_buildout_args(self.buildout_args[1:]) File "/Users/mauritsvanrees/shared-eggs/mr.developer-1.21-py2.7.egg/mr/developer/common.py", line 329, in parse_buildout_args raise ValueError('Invalid option:', option) ValueError: ('Invalid option:', 'parts') Simple buildout for this error: [buildout] extensions = mr.developer parts = hello [hello] recipe = collective.recipe.cmd on_install = true on_update = true cmds = echo Hello In the Plone core-dev buildout, I get an error which at first seemed to be a problem in zc.buildout itself. It goes away when I remove the buildout.dumppickedversions extension though. This is the traceback: While: Installing. Checking for upgrades. Traceback (most recent call last): File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/buildout.py", line 1752, in main getattr(buildout, command)(args) File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/buildout.py", line 447, in install self._maybe_upgrade() File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/buildout.py", line 879, in _maybe_upgrade allow_hosts = self._allow_hosts File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/easy_install.py", line 738, in install return installer.install(specs, working_set) File "/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/easy_install.py", line 574, in install for dist in self._get_dist(requirement, ws): TypeError: get_dist() takes exactly 4 arguments (3 given) When started in debug mode, I get this info: Starting pdb:
/Users/mauritsvanrees/shared-eggs/zc.buildout-2.0.0b1-py2.6.egg/zc/buildout/easy_install.py(574)install() -> for dist in self._get_dist(requirement, ws): (Pdb) a self = <zc.buildout.easy_install.Installer instance at 0x1039871b8> specs = ('zc.buildout', 'distribute') working_set = None (Pdb) requirement Requirement.parse('zc.buildout==2.0.0b1') (Pdb) ws <pkg_resources.WorkingSet object at 0x100436d10> (Pdb) pp ws.entries [] (Same with Python 2.7.) Sample buildout for this error: [buildout] extensions = buildout.dumppickedversions parts = hello [hello] recipe = collective.recipe.cmd on_install = true on_update = true cmds = echo Hello -- Maurits van Rees: http://maurits.vanrees.org/ Zest Software: http://zestsoftware.nl
On Mon, Jan 21, 2013 at 11:11 AM, Maurits van Rees <m.van.rees@zestsoftware.nl> wrote:
Op 21-01-13 13:31, Jim Fulton schreef:
Changes:
http://pypi.python.org/pypi/zc.buildout/2.0.0b1#b1-2013-01-21
If problems aren't discovered first, I plan to make the final release next weekend.
To install the new release, download:
http://downloads.buildout.org/2/bootstrap.py
if you haven't already. (It hasn't changed since 2.0.0a6.)
Then bootstrap projects with:
python bootstrap.py -t
Jim
Works fine in my standard customer buildout.
There are a few problems with extensions I use, but they probably need to be fixed in those extensions.
If I use the mr.developer extension, "bin/buildout buildout:parts=ipzope" works, but not when you spell it without 'buildout:'.
So not a regression.
mr.developer seems to work fine with zc.buildout 2.0.0b1, just not for this feature. This is the traceback:
...
line 329, in parse_buildout_args raise ValueError('Invalid option:', option) ValueError: ('Invalid option:', 'parts')
I have no idea. It's hard to imagine how an extension would be broken unless the extension is actually looking at sys.argv. ...
In the Plone core-dev buildout, I get an error which at first seemed to be a problem in zc.buildout itself. It goes away when I remove the buildout.dumppickedversions extension though.
... dumppickleversions and buildout-versions don't work with buildout 2 because they work by monkey-patching internal buildout implementation that has changed. We agreed to add the functionality to buildout 2. I'm looking forward to a pull request. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
On Mon, Jan 21, 2013 at 11:22 AM, Jim Fulton <jim@zope.com> wrote: ...
dumppickleversions and buildout-versions don't work with buildout 2 because they work by monkey-patching internal buildout implementation that has changed.
But if a change: - was not too big, - not heinous, :) - and someone else figured it out, I would definitely entertain a pull request to make dumppickleversions or buildout-versions work with buildout 2 until the functionality could be incorporated. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
On 21-01-13 17:22, Jim Fulton wrote:
dumppickleversions and buildout-versions don't work with buildout 2 because they work by monkey-patching internal buildout implementation that has changed.
We agreed to add the functionality to buildout 2. I'm looking forward to a pull request.:)
I've taken a quick look at fixing/compensating in buildout-versions: quite doable! https://github.com/reinout/buildout-versions/commit/dc5f487bc36939180bd79e70... It seems to work fine. No import error and no 3-versus-4-arguments error anymore. I suspects the always_unzip=None kwarg trick I used is a quite clean way of working around the buildout 1.x/2.x difference. I just got it working, so I still have to do some cleanup and testing. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"
On 22-01-13 11:37, Reinout van Rees wrote:
On 21-01-13 17:22, Jim Fulton wrote:
dumppickleversions and buildout-versions don't work with buildout 2 because they work by monkey-patching internal buildout implementation that has changed.
We agreed to add the functionality to buildout 2. I'm looking forward to a pull request.:)
I've taken a quick look at fixing/compensating in buildout-versions: quite doable!
https://github.com/reinout/buildout-versions/commit/dc5f487bc36939180bd79e70...
It seems to work fine. No import error and no 3-versus-4-arguments error anymore.
I've packaged it up as a pull request: https://github.com/Simplistix/buildout-versions/pull/7 Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"
On Tue, Jan 22, 2013 at 6:45 AM, Reinout van Rees <reinout@vanrees.org> wrote:
On 22-01-13 11:37, Reinout van Rees wrote:
On 21-01-13 17:22, Jim Fulton wrote:
dumppickleversions and buildout-versions don't work with buildout 2 because they work by monkey-patching internal buildout implementation that has changed.
We agreed to add the functionality to buildout 2. I'm looking forward to a pull request.:)
I've taken a quick look at fixing/compensating in buildout-versions: quite doable!
https://github.com/reinout/buildout-versions/commit/dc5f487bc36939180bd79e70...
It seems to work fine. No import error and no 3-versus-4-arguments error anymore.
I've packaged it up as a pull request: https://github.com/Simplistix/buildout-versions/pull/7
Yay! Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
On 21-01-13 13:31, Jim Fulton wrote:
If problems aren't discovered first, I plan to make the final release next weekend.
I've also tested it with one of my big buildouts. I was especially anxious whether http://pypi.python.org/pypi/osc.recipe.sysegg would work, which we use to grab the system postgres/matplotlib/whatever packages. Hurray: Installing sysegg. sysegg: Using /usr/lib/python2.7/dist-packages for psycopg2 sysegg: Using /usr/lib/pymodules/python2.7 for matplotlib sysegg: Using /usr/lib/python2.7/dist-packages for pyproj Works like a charm, I'd say. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"
On 21-01-13 13:31, Jim Fulton wrote:
If problems aren't discovered first, I plan to make the final release next weekend.
I'm trying to get buildout-versions' tests to run with buildout 2.0b1. The error I'm getting is that it uses zc.recipe.testrunner, which in turn uses z3c.recipe.scripts. That z3c.recipe.scripts is a zc.recipe.egg wrapper, basically, and it fails on "from zc.recipe.egg.egg import ScriptBase": ImportError: cannot import name ScriptBase It might be that zc.recipe.testrunner is horribly old, being last updated in 2010. It might also be that something somewhere needs fixing. Anyone got a pointer/idea? Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"
On Tue, Jan 22, 2013 at 6:40 AM, Reinout van Rees <reinout@vanrees.org> wrote:
On 21-01-13 13:31, Jim Fulton wrote:
If problems aren't discovered first, I plan to make the final release next weekend.
I'm trying to get buildout-versions' tests to run with buildout 2.0b1.
The error I'm getting is that it uses zc.recipe.testrunner, which in turn uses z3c.recipe.scripts. That z3c.recipe.scripts is a zc.recipe.egg wrapper, basically, and it fails on "from zc.recipe.egg.egg import ScriptBase": ImportError: cannot import name ScriptBase
It might be that zc.recipe.testrunner is horribly old, being last updated in 2010. It might also be that something somewhere needs fixing. Anyone got a pointer/idea?
Use zc.recipe.testrunner 1.3.0. I plan to release a zc.recipe.testrunner 2 that is just a copy of 1.3.0. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
On 22-01-13 13:55, Jim Fulton wrote:
Use zc.recipe.testrunner 1.3.0. I plan to release a zc.recipe.testrunner 2 that is just a copy of 1.3.0.:)
Yes, that fixes it. Now I see a different problem: File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2475, in scan_list raise ValueError("Expected "+item_name+" in",line,"at",line[p:]) ValueError: ('Expected version spec in', 'zc.buildout[] ==>=2.0.0b1', 'at', ' ==>=2.0.0b1') I boils down to buildout injecting minimum requirements for buildout and zc.recipe.egg in the version part like ">=2.0.0b1" Apparently this is new? buildout-versions expects only "real" versions in there, so it adds an "==", which results in a weird-looking fat arrow: "==>=2.0.0b1". I think I can compensate for that. But... is it true that you can put ">=" requirements in the versions list? Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"
On Tue, Jan 22, 2013 at 9:11 AM, Reinout van Rees <reinout@vanrees.org> wrote:
On 22-01-13 13:55, Jim Fulton wrote:
Use zc.recipe.testrunner 1.3.0. I plan to release a zc.recipe.testrunner 2 that is just a copy of 1.3.0.:)
Yes, that fixes it.
Now I see a different problem:
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2475, in scan_list raise ValueError("Expected "+item_name+" in",line,"at",line[p:]) ValueError: ('Expected version spec in', 'zc.buildout[] ==>=2.0.0b1', 'at', ' ==>=2.0.0b1')
I boils down to buildout injecting minimum requirements for buildout and zc.recipe.egg in the version part like ">=2.0.0b1"
Apparently this is new?
Yup
buildout-versions expects only "real" versions in there, so it adds an "==", which results in a weird-looking fat arrow: "==>=2.0.0b1".
I think I can compensate for that.
But... is it true that you can put ">=" requirements in the versions list?
Yes: http://pypi.python.org/pypi/zc.buildout/2.0.0b1#a5-2012-12-01 http://pypi.python.org/pypi/zc.buildout/1.7.0#id9 This isn't expected to be a widely used feature. It's used by buildout 2 to keep itself from downgrading itself to a final release. It's used by buildout 1 to keep itself and some recipes from upgrading to 2. I'm surprised buildout 1.7.0 didn't break buildout-versions. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
participants (3)
-
Jim Fulton -
Maurits van Rees -
Reinout van Rees