buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <as...@labnotes.org>
Subject Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Date Thu, 09 Jul 2009 02:09:33 GMT
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