Jim Fulton wrote:
On Sep 5, 2007, at 10:48 AM, Chris Withers wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated than it
already is.
Indeed, but surely managing known good sets of components comes
under its remit of version management?
Sure. It does this
Martin Aspeli wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated than it
already is.
Indeed, but surely managing known good sets of components comes
under its remit of version management?
Sure. It does this via requirements.
Ok, forgive me for being dumb
On 9/6/07, Chris Withers [EMAIL PROTECTED] wrote:
Yup, and this was the reason for my original question to Jim: why do
something in zc.buildout rather than fixing the problems with setuptools?
It's not at all clear to me that this suggests there's actually a
problem with setuptools. The desire
On Sep 6, 2007, at 4:02 AM, Chris Withers wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated
than it already is.
Indeed, but surely managing known good sets of components
comes under its remit of version management?
Sure. It does
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated than it
already is.
Indeed, but surely managing known good sets of components comes under
its remit of version management?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
-
On Sep 5, 2007, at 10:48 AM, Chris Withers wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated than it
already is.
Indeed, but surely managing known good sets of components comes
under its remit of version management?
Sure. It does this via
Philipp von Weitershausen wrote:
As far as I understand your use case, i twould already be covered by my
original proposal: you always have the option to locally override what's
specified in the working set.
I think Dieter may have meant something like:
[grok-0.11]
grok = 0.11
ZODB =
On 4 Sep 2007, at 10:15 , Chris Withers wrote:
Philipp von Weitershausen wrote:
As far as I understand your use case, i twould already be covered
by my original proposal: you always have the option to locally
override what's specified in the working set.
I think Dieter may have meant
On Sep 3, 2007, at 4:13 PM, Philipp von Weitershausen wrote:
Wichert Akkerman wrote:
The only problem is that distributing grok-0.11.cfg is a bit
tedious. How about if buildout could get it from the web?
How about making it available from an egg, through a hook in egg-info
perhaps?
This
Chris Withers wrote at 2007-9-4 09:15 +0100:
Philipp von Weitershausen wrote:
As far as I understand your use case, i twould already be covered by my
original proposal: you always have the option to locally override what's
specified in the working set.
I think Dieter may have meant something
On 4 Sep 2007, at 16:13 , Jim Fulton wrote:
How would the known_working_versions be used? You haven't
specified that.
You're right, I forgot that. In buildout.cfg, you'd then say:
[buildout]
versions = egg:grok==0.11
which would load the grok 0.11 egg before doing anything else,
11 matches
Mail list logo
