Hi,
Martijn Faassen schrieb:
David Pratt wrote:
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'
I want to tell buildout what to do have it do it without surprise as
well. I was surprised when it didn't do what I expected: give priority
to the develop package. Why else would I choose to put it on the develop
line?
I take it you have run into this and weren't surprised at all, then?
I think the explicit versus implicit discussion has no place here.
Placing a package on the 'develop' line is a very explicit action, and
you place it on that line because you want to *develop on it*. Having
another package being picked up is surprising.
OTOH it makes you aware about potential version mismatches very early,
because you try to develop on a package that doesn't seem to be
supported by that particular buildout. So maybe you, for example
actually wanted/should increase the version number.
I realize that it has a reason: it does what you tell it do. But lists
of locked versions are things that are frequently maintained offline -
even sitting off on some URL, and maintained by someone else. Yes,
indirectly you are telling buildout about versions, but you may not be
very aware of it. These are long lists, after all. It'd be nice if these
lists could be treated as mostly opaque (encapsulation) and that you can
simply look at what's in setup.py instead.
That is not possible now. You need to *know* that it lists the package
you are trying to hack on, and you need to know that you need to add it
to [versions]. The workaround I find myself using frequently now is this:
[versions]
the_package =
I don't see the point when I already say this in 'develop'.
See above. However, I agree that buildout should make it more obvious
what's happening. Maybe, as a supportive action, buildout could tell
that or why a development package was not picked (whenever an egg with a
similar name is required) and give a warning (like when variables are
unused)
Christian
--
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
_______________________________________________
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 )
