search

Perl-Critic / Test-Perl-Critic

Run Perl::Critic as a unit test
http://perlcritic.com
Other
9 stars 7 forks source link

Support external perlcritic command? #16

Open iynehz opened 6 years ago

iynehz commented 6 years ago

At my workplace we have a special Perl package installation and usage mechanism that, we install CPAN packages to non-standard paths and we need to explicitly specify the paths of all the dependency packages (like by PERL5LIB or @INC) before using them. So when we develop/build/test our internal Perl library, the exact list of its dependencies are decided. This causes an annoying problem with Test::Perl::Critic that, if we use Test::Perl::Critic in our tests, we would need to add its dependencies, most of which are indirectly introduced by Perl::Critic, into the list. If there be the option to use an external perlcritic command, we would be able to decouple the non-trivial list of dependencies of Perl::Critic from that of our own libraries, and have our re-engineered perlcritic command to handle its own dependencies.

I know it sounds like a non-standard requirement. But I would like to bring it up for discussion here and hope it can be implemented in Test::Perl::Critic. In case you don't have interest, I will write a new module myself and put onto CPAN.

thaljef commented 6 years ago

Unlike your other unit tests, Test::Perl::Critic doesn't actually load any of your libraries; it just sees them as files. So T::P::C doesn't need to have the same module environment as your libraries. So unless I misunderstand the gist of your request, I think you can already do what you want. You just have to invoke the T::P::C test script separately.

iynehz commented 6 years ago

@thaljef Let me explain it in more details.

At my workplace Perl modules are not located naturally, and basically every package has a different lib path. The Perl interpreter by default does not see any non-core modules. When I test my library, I need to explicitly manipulate @INC, like hardcoding use lib in my test files, or more generically via prove's -I option or changing PERL5LIB, to specify the exact locations of my library dependencies. And those lib paths are my test dependencies.

Now I am re-engineering DZIL for my workplace as an internal build tool for Perl projects. With that thing I have Dist::Zilla::Plugin::Test::Perl::Critic for generating an additional test file that calls T::P::C. But because of the special environment as I explained above, when I "prove" this T::P::C test file, I will also need to explicitly inject T::P::C's dependencies, as otherwise the test file cannot run. If I don't re-engineer Dist::Zilla::Plugin::Test::Perl::Critic to change the auto-generated test file, then I would need to add dependencies of T::P::C into prove's -I option or PERL5LIB. But that change is possible to affect all test files, including my library's own test files.

As indicated above, an alternative approach for me can be to re-engineer Dist::Zilla::Plugin::Test::Perl::Critic to hack its generated test file. But as our perlcritic is already re-engineered, it would be great if T::P::C itself can support external perlciritic.