Hey,
On Thu, Feb 28, 2008 at 7:41 AM, Christian Theune [EMAIL PROTECTED] wrote:
[snip]
but I don't see it flying
given the sentiments against that idea so far. Perhaps I'm wrong.
Humm. Maybe there's just a misunderstanding. I didn't get that you
wanted to only trump version pinning,
Hi,
Martijn Faassen schrieb:
Christian Theune wrote:
[snip]
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.
I'd be happy with that too, and was really what I was
On Tue, Feb 26, 2008 at 3:38 PM, Christophe Combelles [EMAIL PROTECTED] wrote:
But probably the feature has been created before the name 'develop' was
chosen,
and it should have an other name ('egg_path'? 'local_egg'?).
source_egg?
--
Lennart Regebro: Zope and Plone consulting.
Hi,
Martijn Faassen schrieb:
Christian Theune wrote:
Martijn Faassen schrieb:
[snip]
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*.
Previously Martijn Faassen wrote:
Christian Theune wrote:
Martijn Faassen schrieb:
[snip]
It's a clear DRY violation, the name of the package (and even the
version number) repeats here.
It's not clear to me that it's a DRY violation (see my argument that
those functions are actually
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Christian Theune wrote:
Martijn Faassen schrieb:
[snip]
It's a clear DRY violation, the name of the package (and even the
version number) repeats here.
It's not clear to me that it's a DRY
Martijn Faassen a écrit :
(...)
I think the term 'develop' is badly chosen. You are right if you argue while
having the meaning of 'develop' in mind. You are explaining what you think a
'develop' option should be. A 'develop' option means: I want to 'develop' on
this package, so I want it
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
Aaron Lehmann a écrit :
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
On Feb 26, 2008, at 10:29 AM, Martijn Faassen wrote:
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
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
Hi,
Martijn Faassen schrieb:
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
Hi,
Martijn Faassen schrieb:
Christian Theune wrote:
Stephan Richter schrieb:
On Saturday 23 February 2008, Jim Fulton wrote:
The additional version specification should be merged into the
extends version
section. The version 1.3.1dev is the version the develop egg
specifies.
Yes.
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
14 matches
Mail list logo