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 <as...@labnotes.org> wrote: > On Wed, Jul 8, 2009 at 5:58 PM, Alex Boisvert <boisv...@intalio.com> > wrote: > > > On Wed, Jul 8, 2009 at 5:50 PM, Daniel Spiewak <djspie...@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 > > >
