[Zope-dev] Re: buildout 'versions' and 'develop' conflict

[Christian Theune]

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 - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development