Martijn Faassen schrieb:
Christian Theune wrote:
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
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.
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
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
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.
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
** No cross posts or HTML encoding! **
(Related lists -