On Tue, Sep 03, 2002 at 11:26:01AM +1000, Ken Williams wrote: > >>Thus is you need to be in t this might suit > >> > >> cd t; perl -Mblib=lib foo/bar.t > > I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir "t"'.
It already happens inside TestInit. > I'd be happier still if tests didn't run from t/, since that's > not how most CPAN modules work. The trouble here is we don't want tests running from the top level. Too much chance of them overwriting something they shouldn't be, or writing a file and forgetting to clean it up. Or touching the wrong directory, etc... So t/ is used as a safer location. It's also used just because that's what all the other tests do, so there's some cargo-cult/needless tradition. So they can't run from the top level directory, and at that point you're already different than CPAN. However, we can chdir for them, that's not hard. > >There's a chicken/egg problem here. blib.pm is going to find the lib/ > >directory so we can load uninstalled modules. So... how do you find > >blib.pm? > > This doesn't seem like a real problem. The test suite can find > it because it knows where it's being run from. It can set up > @INC however it wants, to make sure blib.pm is found. Then > blib.pm sets things up for the rest of the tests. I thought the whole idea was to run blib.pm to set @INC. If the test suite is setting up @INC we don't need blib. And if we're not using blib to setup @INC there's no point in shoving extra functionality unrelated to finding modules into it. Put it into something else. Like TestInit.pm, which already has all this. > >Other problems include that we can't assume blib.pm works. > >Don't want the > >whole basic test suite falling apart because of a module failure. > > For core perl, we can indeed assume blib.pm works. If it > doesn't, we want to know about it right away. You want to be able to continue with basic testing even in the event of a catastrophic failure. There was a big discussion along these lines about at what point in the tests we can start relying on modules, this was about using things like Test and Test::More in basic core tests. The result was that 'make test' should rely on as little as possible and I agree with that. Worse, blib relies on Cwd.pm and File::Spec. If any of these fail the test suite doesn't work at all. No good. > >Finally, since you have to run from t/ anyway, blib.pm is > >overkill. This > >works just as well: > > > > cd t; ./perl -I../lib foo/bar.t > > I have to wonder why it's preferable to put code on command > lines rather than in modules. As mentioned below, it's not. That's why it's already in TestInit.pm (are you sensing a theme here?) I was just spelling out the equivalent command to show blib wasn't buying us anything. > Really, it would be nice if you could tell the module about > certain situations, like -MTestInit=core or whatever, and that > would do whatever's necessary for a core test run (including > chdir, @INC adjustments, etc.). TestInit is a module only available and useful in the core for doing the special little things necessary to run a CPAN-style test as a core test. There wouldn't be anything to do otherwise outside the core. > Heck: with a smart enough TestInit, it could even adjust @ARGV > so that you could specify all *.t paths in Unix format, if that > would be helpful. Hmmm. I can't think of a use. > >and perhaps reduced a little further by moving/linking > >TestInit.pm into the > >top level directory. > > > > ./perl -MTestInit t/path/to/test.t > > > >but that will cause trouble when running tests with -T (because . is no > >longer in the path). > > '.' won't necessarily be in the path anyway. Sorry, I ment perl's @INC. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Not king yet
