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

[David Pratt]

Hi Martijn. I respect the points you make, but disagree with your 
comments. Wichert's reply accurately articulates what we are asking 
buildout to do. I share this view.

On a personal note, I tend to rely on my own version lists but refer to 
the online lists (for support in creating them). On explicit vs 
implicit, it is debatable any time you consider incorporating implicit 
behaviour.

When you make the point about versions duplication, you may not be 
considering the utility of buildout. In fact, a buildout does not 
require a setup.py at all. setup.py is only a requirement for packaging 
in python. Buildout is already being used together with other packaging 
solutions and in other ways as I have previously mentioned. Overall, 
buildout cfg files are an abstraction. Its most attractive features are 
that it is simple, readable, fairly well documented and without a great 
deal of obfuscation or magic. You may consider a recipe and utility 
script that uses versions to help build a setup.py. It would seem more 
in line with the character of the software.

Regards,
David


Martijn Faassen wrote:
> 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.
> 
> 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'.
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at 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 )
>