From zeta-dev-return-705-apmail-incubator-zeta-dev-archive=incubator.apache.org@incubator.apache.org Thu Apr 14 10:04:12 2011 Return-Path: Delivered-To: apmail-incubator-zeta-dev-archive@minotaur.apache.org Received: (qmail 64406 invoked from network); 14 Apr 2011 10:04:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Apr 2011 10:04:11 -0000 Received: (qmail 73391 invoked by uid 500); 14 Apr 2011 10:04:11 -0000 Delivered-To: apmail-incubator-zeta-dev-archive@incubator.apache.org Received: (qmail 73353 invoked by uid 500); 14 Apr 2011 10:04:11 -0000 Mailing-List: contact zeta-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zeta-dev@incubator.apache.org Delivered-To: mailing list zeta-dev@incubator.apache.org Received: (qmail 73345 invoked by uid 99); 14 Apr 2011 10:04:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 10:04:11 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of giunta.gaetano@gmail.com designates 74.125.82.175 as permitted sender) Received: from [74.125.82.175] (HELO mail-wy0-f175.google.com) (74.125.82.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 10:04:04 +0000 Received: by wye20 with SMTP id 20so1381959wye.6 for ; Thu, 14 Apr 2011 03:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uq4jzUl/6GEIU8Iz1Z9w01zbfMurYrkvDcDkhiwpsfI=; b=wP/VK8Oqhx6qiMf6tva8qQsYhL9o0hDGcqAIsr68FzfEvCcupU1f0tf2FQiZaS0v8x jz4GQZv8EU9QjypWcLQqFKZWQEerIWhUDGrB4MUw+OEI9Cr/OWACcfdiogmNp8SA1w02 x92XBf9/LXLqZRwkgXXimyZo4IzqyqR5Wyuas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=OQAbZmUjRH/aPPwz+0ciOUsEv4AkLcp6rav9CW371UIVhZgz3gvHEyR3HTWqeDxLT/ XyB/31fX0g+6QkqwnKrMGfhm4D2TRf9pOOqD9+kgAc+8GjHS5ZhZfeGPloKtFpSPjm9d MRvj14zPHR3MGpkx2DjeIcw0O+XLa/suDqmUk= Received: by 10.227.178.5 with SMTP id bk5mr612703wbb.173.1302775422680; Thu, 14 Apr 2011 03:03:42 -0700 (PDT) Received: from [10.1.7.2] (ppp-184-143.15-151.iol.it [151.15.143.184]) by mx.google.com with ESMTPS id o23sm880825wbc.61.2011.04.14.03.03.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2011 03:03:41 -0700 (PDT) Message-ID: <4DA6C682.80107@gmail.com> Date: Thu, 14 Apr 2011 12:03:46 +0200 From: Gaetano Giunta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: zeta-dev@incubator.apache.org References: <4DA4748A.4090804@gmail.com> <4DA6A4DD.8010205@gmail.com> <4DA6BD12.1030704@gmail.com> <4DA6C1AF.7070208@schlitt.info> In-Reply-To: <4DA6C1AF.7070208@schlitt.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [zeta-dev] PHP based build system : Phing VS Pake Tobias Schlitt wrote: > On 04/14/2011 11:36 AM, Jerome Renard wrote: > >>> I still prefer cli options than env vars for 90% of the time though, as it's >>> easier to understand what is happening when the options are explicit. >>> >>> But, as far as I can see in your code, what you can do is that you can swap >>> out one config file with another. >>> >>> What I was asking to is to separate cofig options: one set that is >>> project-specific (stored in the config file), and one set that is specific >>> to the build environment (passed via cli options or env vars). >> I'll see how to pass arguments from the command line in Pake then. > I'd suggest to use some kind of "properties" file for configuration. Yaml is the pake-equivalent of properties. Is it fine with you to have yaml files for config? > At least that is what we do when using ant. Our scripts ship with a > build.properties file and the script itself looks for > build.local.properties. If this doesn't exist, it bails out with a > message that the user should copy and adjust the original file. > > This way is pretty convenient and most obvious I'd say. Kind of ok, but why not instead: - take properties from build.properties file (which is complete) - if build.local.properties is there, use it to override existing properties (if it's not where, just continue) This way there is no need to copy files around, and the original properties file can be kept in sync easily with the upstream svn/git version.