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

[Martijn Faassen]

David Pratt wrote:
> 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.

It's not very useful to talk about a "we" asking buildout to do things 
when there is clearly a debate and no "we".

> 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.

We're not considering incorporating implicit behavior. We're debating 
two competing explicit behaviors.

> 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.

I don't understand your point. Explain to me how you can use the 
'develop' line *without* it pointing to a package with a setup.py? 
Explain to me how 'versions' can be applied to version numbers of things 
that are *not* eggs?

There is a genuine debate possible over what 'develop' actually does. If 
you ignore version pinning, you can have two descriptions:

* if you want to develop a package, put it under 'develop'.

* listing a package under 'develop' adds it to the package search path 
for packages *and* this package will trump any other versions available 
elsewhere on the path.

These descriptions are equivalent, though one is task-oriented and the 
other one talks about the details of what's going on. I had internalized 
the former model, and was surprised when it was broken when version 
pinning was included.

Evidently the rule for 'develop' is now:

* listing a package under 'develop' adds it to the package search path 
for packages *and* this package will trump any other versions available 
elsewhere on the path *unless* there is an explicit version pinning 
indicator that says you want to use that version of the package.

The task oriented description to develop a package becomes:

* if you want to develop a package, put it under 'develop', and just to 
be sure it isn't pinned in some version list somewhere, add a 'versions' 
entry to your buildout if it doesn't exist already, and then list 
"package_name =" in it to make sure it is being picked up.

(alternatively you can make the user check the versions lists for the 
presence of the package and only if it there have the user list it. Or 
yet another alternative is to run the buildout in verbose mode and look 
at what versions pass by)

Regards,

Martijn