Hi Christophe. Wichert has just responded with the point I was going to
make in reply. I can agree with your point that emitting warnings are
helpful for misconfiguration or if there has been duplication. I am
opposed to incorporating the type of automatic character that has been
suggested.
Regards,
David
Christophe Combelles wrote:
David Pratt a écrit :
Hi. I agree with Jim. Buildout is doing the right thing. This is not a
conflict since you have explicitly identified the software with a
version already. I think the right thing to do under the circumstances
would be to append a custom versions.cfg to nail the versions you
want. KGS versions is a point in time list and it does not apply to
the full scope of what buildout is being used for. I believe this
should be kept in mind since it serves more than z3.
Changes to buildout to have it automatically do the 'right' thing
opens the implicit versus explicit argument. A developer would then
need to be aware of the implicit cases that would cause a different
software selection. Much like zcml configuration in zope, I want to
tell buildout what to do and have it do it without surprise (or for
that matter fighting any implicit nature folks may be inclined to give
it). While I understand the concern about the development egg for your
build, I would see any move in this direction as corrupting the nature
of buildout to 'do what you have told it to do'.
Hi,
I don't think this is a matter of implicit versus explicit, because
there are two explicit configurations: one explicit 'version', and one
explicit 'develop'.
I think the question is about what to choose between two explicit
configurations that are potentially conflicting.
There can be arguments for giving priority on one of them.
Maybe the best thing here would be to just warn the user (in stdout)
about the conflict. Buildout should tell him that either the specified
version won't be used, or the develop-egg won't be used.
regards
Christophe
Regards,
David
Jim Fulton wrote:
On Feb 23, 2008, at 9:26 AM, Christophe Combelles wrote:
I don't have enough experience with all the use cases of buildout
and the develop-eggs, but at a first glance, I find it more logical
to give priority to 'develop':
'develop' is supposed to point to a real path containing a setup.py,
so when defining a develop-egg, you clearly indicate that you want
*that* path, whathever version this develop-egg defines.
That is the philosophy that buildout takes. That's why, when picking
versions, buildout prefers develop eggs over newer non-develop eggs.
However, buildout will only use a develop egg if it satisfies stated
requirements. As it stands today, specifying a version in a versions
section is like stating a == requirement in a setup script or in a
eggs option.
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 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 )
