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

[Christian Theune]

Hi,

Martijn Faassen schrieb:
> Christian Theune wrote:
> [snip]
>> Nope. I'm not always working against a fixed version list. E.g. when I
>> developt z3c.zalchemy then this is a library package, not an
>> application, so I don't fix the versions but let anything that satisfies
>> the the requirements in setup.py come in.
> 
> This thread is called 'buildout "versions" and "develop" conflict, and I 
> was talking about that topic. I can see how this is related to other 
> topics from the perspective of consistency arguments, but perhaps you 
> should be more clear. :)

Sorry, I thought I was.

>> In this situation I might use a checkout of SQLAlchemy that doesn't
>> match the version requirement so it doesn't get picked. (I.e. there are
>> two branches of zalchemy, one for SA 0.3 and one for 0.4)
> 
> And you're listing both of them in 'develop'?

No, I usually only eneter one.

> Fred pointed out to me that you might want to rely on the same package 
> but different versions multiple times in a buildout. I can see how this 
> can be useful, but I don't see how one can use the 'versions' 
> construction of the [buildout] section and do this.

That's a valid use case too, it's not mine though (right now).

>> I don't want to start developing on the 0.3 branch using SA 0.4
>> accidentally.
> 
> I think that this information should be codified in the setup.py 
> requirements of your package. If it relies on 0.3, it should say so with 
> a dependency range. I don't think pinned versions are very useful to 
> stop you from making accidents here.

That's what I do. That allows me to notice when I include the wrong 
develop package because it will not be picked up. (In spite of other 
people that posted to this thread who seem to prefer not to care about 
this problem during development.)

>> buildout can be and is used in a much broader way than just applications
>> that provide fixed versions.
> 
> My summary:
> 
> The consistency argument indicates to me that version pinning should 
> have the same effect as listing version constraints in setup.py. A 
> reasonable argument. Since version constraints are the most specific 
> constraints possible, if there is no constraint conflict they will be 
> the ones picked.

Right, that's my understanding as well.

> There is a use case argument that allows the listing of multiple 
> versions of a development package in 'develop' at the same time, and 
> then have different parts of the buildout pick up on it. Sounds like a 
> valid use case. I wonder though what will be picked up if you *don't* 
> specify the version explicitly later on in your buildout. Unspecified 
> behavior?

Good question.

> Having multiple versions of the same package listed in the 'develop' 
> section can never work, I take it, in the face of version pinning. If 
> you have two versions listed in 'develop' and want to use different ones 
> in different sections of your buildout, you can't do this in the face of 
> a global version list, right? I'd say the consistency argument implies 
> buildout should fail with an error if you try to use two different 
> versions of a package while the version is pinned down globally.

I think you're right. I haven't given thought whether making buildout 
fail is a good idea, it might be though.

> The task-driven and most-common use case argument ("I want to develop!") 
> have made the 'develop' section trump any other listed packages if the 
> version constraints allow both. This is the current behavior.
> 
> The task I am concerned about entails wanting to hack on a package that 
> is pinned down. This is in my experience very common in the face of 
> shared lists of pinned versions (from the KGS or Grok).
> 
> In the face of such lists, it's not very pleasant to have to explain to 
> people who want to hack on a package that they should also add the 
> package to the 'versions' section of a buildout to override any entry of 
> them in the list.
> 
> The goal of this feature is to allow us to tell people the following:
> 
> * if you want to hack on a package, check it out into your buildout and 
> add it to 'really_develop', and then re-run bin/buildout.
> 
> and that this will work even in the face of explicit version pinning.

I really hate the term `really_develop` and I don't like having two 
develop statements.

Here's an idea:

Let `develop` trump version pinning, but not any other constraints.

As far as I can see this would allow both of our scenarios to work or 
continue to work.

 > [snip]

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