On Mon, Apr 19, 2010 at 10:28:37AM -0400, Jim Fulton wrote:
> On Mon, Apr 19, 2010 at 10:00 AM, Florian Friesdorf wrote:
> > Hi Jim, hi Christian,
> >
> > any further thoughts on this?
>
> Not at this time. This is on my to-do list to look at.
>
> I think your use case would be better handled th
On Mon, Apr 19, 2010 at 10:00 AM, Florian Friesdorf wrote:
> Hi Jim, hi Christian,
>
> any further thoughts on this?
Not at this time. This is on my to-do list to look at.
I think your use case would be better handled through
normal command-line option specification, as in:
buildout -c deploy
Hi Jim, hi Christian,
any further thoughts on this?
best regards
florian
On Fri, Apr 09, 2010 at 05:23:36PM +0200, Florian Friesdorf wrote:
> On Fri, Apr 09, 2010 at 10:16:51AM -0400, Jim Fulton wrote:
> > > We currently use it for 5 very similar sites that share one repository
> > > but use 5 c
On Fri, Apr 09, 2010 at 10:16:51AM -0400, Jim Fulton wrote:
> > We currently use it for 5 very similar sites that share one repository
> > but use 5 checkouts of it:
> >
> > base.cfg
> > [buildout]
> > parts = instance
> >
> > develop = ...
> > eggs = ...
> > zcml = ...
> >
> > [instance]
> > ...
>
On Thu, Apr 8, 2010 at 9:32 AM, Florian Friesdorf wrote:
> On Thu, Apr 08, 2010 at 02:24:53PM +0200, Christian Theune wrote:
>> Hi,
>>
>> On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
>> > On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
>> >> On 04/08/2010 04:27 AM, Florian Fr
On Thu, Apr 08, 2010 at 04:45:30PM +0200, Adam GROSZER wrote:
> Maybe you should take a look at keas.build.
> Tho not repo based, but solves such "almost identical sites" cases.
I will take a look into it, but for my use case it seems overkill and
depends on svn, without support for git.
--
Flor
Hello Florian,
Thursday, April 8, 2010, 3:32:22 PM, you wrote:
...
FF> We currently use it for 5 very similar sites that share one repository
FF> but use 5 checkouts of it:
Maybe you should take a look at keas.build.
Tho not repo based, but solves such "almost identical sites" cases.
--
Best
On Thu, Apr 08, 2010 at 09:01:58AM -0400, Jim Fulton wrote:
> On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote:
> > I wonder what Jim thinks about the topic.
>
> I have mixed feelings. Accessing environment variables seems
> reasonable on some level, however:
>
> - I'd worry about the cho
On Thu, Apr 08, 2010 at 02:24:53PM +0200, Christian Theune wrote:
> Hi,
>
> On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
> > On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
> >> On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
> >>> environment variable support for zc.buildou
On Thu, Apr 8, 2010 at 9:05 AM, Christian Theune wrote:
...
> Can you use any variable expansion in the values given in the [buildout]
> section anyway?
Only in a limited way that isn't well defined. :) Probably, you can't
use expansion
for options that are used early -- before the substitutions
On 04/08/2010 03:10 PM, Fred Drake wrote:
On Thu, Apr 8, 2010 at 9:03 AM, Christian Theune wrote:
The "special" that I was referring to was the fact that you don't have to
spell a recipe name for that section (like the buildout section).
There are many times you can have a section that isn't
On Thu, Apr 8, 2010 at 9:03 AM, Christian Theune wrote:
> The "special" that I was referring to was the fact that you don't have to
> spell a recipe name for that section (like the buildout section).
There are many times you can have a section that isn't a part; the
buildout section is just that,
On 04/08/2010 03:01 PM, Jim Fulton wrote:
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote:
I wonder what Jim thinks about the topic.
I have mixed feelings. Accessing environment variables seems
reasonable on some level, however:
- I'd worry about the choice of the virtual section nam
On 04/08/2010 02:57 PM, Fred Drake wrote:
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote:
Maybe a specialised part-name, like versions would be helpful so that
buildout could pre-populate that part during initialisation and then
allow configurations to override individual values.
It's
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote:
> I wonder what Jim thinks about the topic.
I have mixed feelings. Accessing environment variables seems
reasonable on some level, however:
- I'd worry about the choice of the virtual section name. "env" or
"environment" seems too likely
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote:
> Maybe a specialised part-name, like versions would be helpful so that
> buildout could pre-populate that part during initialisation and then
> allow configurations to override individual values.
It's probably worth mentioning that "version
Hi,
On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
> On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
>> On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
>>> environment variable support for zc.buildout, including extends!
>>>
>>> https://bugs.launchpad.net/zc.buildout/+bug/5577
On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
> On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
> > environment variable support for zc.buildout, including extends!
> >
> > https://bugs.launchpad.net/zc.buildout/+bug/557769
> >
> > works for me so far
>
> Uhm ... interesting.
On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
> environment variable support for zc.buildout, including extends!
>
> https://bugs.launchpad.net/zc.buildout/+bug/557769
>
> works for me so far
Uhm ... interesting. I never noticed our recipe not to work with
extends. Can you give me an example?
environment variable support for zc.buildout, including extends!
https://bugs.launchpad.net/zc.buildout/+bug/557769
works for me so far
--
Florian Friesdorf
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118
20 matches
Mail list logo
