On Sep 25, 2007, at 7:55 AM, Philipp von Weitershausen wrote:
On 25 Sep 2007, at 13:20 , Jim Fulton wrote:
On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote:
Charlie Clark wrote:
Am 25.09.2007 um 02:05 schrieb Tres Seaver:
I'd like to break the remaining CMF packages out (moving from '/
CMF' to
'Products.CMFCore', 'Products.CMFDefault', etc.) and push the
2.1.0 eggs
out, as well as equivalent changes for PluggableAuthService and
PluginRegistry.
Any objections, or other thoughts?
While I am very sceptical about the move to eggs (I know it's
inevitable) and I hope we can avoid some of the problems that
seem to be affecting Grok as a result.
Grok's problems are primarily related to the lack of a working
set definition for Zope 3.
I don't know what you mean by this.
There are several problems.
* We've had to nail some of the versions because buildout was being
a bit over-zealous when getting eggs on Windows. It would take the
newest egg, despite the fact that other eggs had binary releases. I
guess that's not its fault. But it's a working set problem.
It's probably a setuptools problem. It would probably make sense to
give buildout a switch to prefer binary releases where they are
available. (Perhaps the new prefer-final option would help here.)
* When package A depends on Y and package B also depends on Y, but
with some version restrictions, buidout will first try to get the
newest version of Y when installing A. But then when installing B,
it is likely that it has to get a different version of Y. The
result is a version conflict. This could also easily be fixed with
a working set that dictates which versions would be used from the
beginning.
IN the long run, this would be better served by a better algorithm
for constructing setuptools working sets.
BTW, since "working set" has a rather important meaning for
setuptools, I'd rather we find a different term for what you are
talking about.
* Even with newest=false enabled in grokproject's buildout.cfg
template, the versions that people will end up when trying out grok
are non-deterministic. This has led to people installing newer
versions of something, sometimes even faulty releases, even though
Grok hadn't been tested with these newer versions yet and older
versions that were known to work were the better choice. Again, a
working set problem.
Right, but I don't understand how having one of these things for Zope
3 would help. After all, a new package that is tested and added to
the 3.4 release might still not work well with Grok.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
Zope-PAS mailing list
Zope-PAS@zope.org
http://mail.zope.org/mailman/listinfo/zope-pas
