buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <djspie...@gmail.com>
Subject Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Date Thu, 09 Jul 2009 02:15:20 GMT
I didn't realize that Rake handled the envar vs command-line invocation
automatically.  That of course changes things.  I'm still not happy with
using "test" as an environment variable, but I don't have a better solution
to offer.

Daniel

On Wed, Jul 8, 2009 at 9:09 PM, Assaf Arkin <assaf@labnotes.org> wrote:

> On Wed, Jul 8, 2009 at 5:58 PM, Alex Boisvert <boisvert@intalio.com>
> wrote:
>
> > On Wed, Jul 8, 2009 at 5:50 PM, Daniel Spiewak <djspiewak@gmail.com>
> > wrote:
> >
> > > > If it broke, I'll probably spend an hour of frustration before I
> catch
> > > why
> > > > my tests are not working as expected. On the other hand, buildr
> package
> > > > test=no vs buildr package build_test=no ... no contest.  And I like
> > being
> > > > able to export test=no.
> > >
> > >
> > > I agree 100% that it should remain `buildr package test=no`.  It would
> > > drive
> > > me batty if we changed that.  However, I question whether export
> test=no
> > is
> > > really all that useful.  Or, more importantly, I question whether
> `export
> > > BUILDR_TEST=no` is really all that inconvenient.  To me at least, this
> > > looks
> > > a lot more representative of what it's doing (setting the TEST property
> > for
> > > the BUILDR tool).  I don't think there would be any confusion if we had
> > > BUILDR_TEST for the envar and test for the invocation form,
> particularly
> > > since one is capitalized while the other is not (as per the Unix
> > > convention).
> >
> >
> > This would be my preference as well... with the caveat that variable
> > bindings passed on the command-line would be specific to Buildr and no
> > longer general environment variable equivalents.   I understand it would
> > break from Rake conventions as well.
>
>
> That means duplicating the number of variables that control testing,
> complicating documentation, specs and code, creating one-off special case
> for that one variable, either writing spaghetti around rake's envvar
> handling, or duplicating code that already works.
>
> If we do that, should we be solving a real problem?
>
> This "problem" has been around since before 1.0, and I'm looking at the
> cost
> so far (of not having it fixed), versus the cost of having it fixed, and
> cold hard calculation says we should leave it alone.
>
> Assaf
>
> >
> >
> > alex
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message