Aaron Lehmann wrote:
On Feb 26, 2008, at 9:38 AM, Christophe Combelles wrote:
Martijn Faassen a écrit :
The two easiest choices are 1) issue a clear warning in stderr, or 2)
rename 'develop' to something else.
So, the people that understand either get spammed with warning messages
every build, or have to change all their builds in order to accommodate
your thinking? We all know what the solution is, it was supplied at the
beginning of the thread:
mynewpin = somenewversion_dev
It's longer and shorter:
* longer: create a 'versions' section if it isn't there yet, and point
to it from [buildout] with 'versions'. (the versions section may not be
there yet if this buildout.cfg extends another one with such a section)
Removes the pin. In the absence of a pin, it will pick the newest
version. Or perhaps I'm wrong about this somehow, as I couldn't get the
test case to work when I added it to buildout. :)
There are two problems with this solution, both usability related:
* People tend to be surprised when they first run into this. The
solution is non-obvious in the face of external version lists. It can be
expected people will be surprised in the future.
* You make people type more, repeating a version name, in a common case
(in the face of KGS)
So, we're looking at a way to increase the usability of a common task:
hack on a package without having to understand its place in a
potentially very complicated dependency structure.
The simplest solution I see to these problems is to add another option
to buildout that does both at the same time (and perhaps override all
other constraints), and direct people to that should they wish to
develop a package.
The name 'develop' was picked which is understandable historically, and
it can't be changed. It's consistent with the behavior of easy_install.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -