You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have many test modules based on Test::More. I have many lines of code that do the standard
local $Test::Builder::Level = $Test::Builder::Level + 1;
but I don't bother including Test::Builder because Test::More always loads it in.
I have other internal-only modules that are the same way: The module that most people use is based on a lower-level module that sometimes gets used, but would be a giant pain to use every time a file uses something inside of it.
It would be nice to have some config option where I can say "If you see Test::More, you are also getting Test::Builder with it, so don't complain."
Maybe it would look like:
[Modules::RequireExplicitInclusion]
freebies = Test::More Test::Builder # Test::More always brings in Test::Builder
freebies = My::User My::SQL My::DB My::Company # My::User always brings in the other three
I would suggest that we NOT have any of these on by default, because some people may want to explicitly require use Test::Builder, for example.
The text was updated successfully, but these errors were encountered:
petdance
changed the title
Provide a mechanism to say module X brings in module Y
Provide a mechanism to RequireExplicitInclusion that "module X brings in module Y" so you don't have to explicitly use it
Dec 12, 2016
petdance
changed the title
Provide a mechanism to RequireExplicitInclusion that "module X brings in module Y" so you don't have to explicitly use it
Provide a mechanism to RequireExplicitInclusion that "module X brings in module Y" so you don't have to explicitly use Y
Dec 12, 2016
This would also allow to solve the problem I face with SOAP::Lite - SOAP/Lite.pm has both package SOAP::Lite and package SOAP::Data, and I can neither use SOAP::Data nor disable RequireExplicitInclusion for the entire block generating a SOAP message (since it is too likely that somebody, possibly me, would introduce future bugs there).
I wonder if a simple list of modules to ignore would be sufficient and easier to implement - I looked at the code and do not see an obvious way to implement it.
I have many test modules based on Test::More. I have many lines of code that do the standard
but I don't bother including Test::Builder because Test::More always loads it in.
I have other internal-only modules that are the same way: The module that most people use is based on a lower-level module that sometimes gets used, but would be a giant pain to
use
every time a file uses something inside of it.It would be nice to have some config option where I can say "If you see Test::More, you are also getting Test::Builder with it, so don't complain."
Maybe it would look like:
I would suggest that we NOT have any of these on by default, because some people may want to explicitly require
use Test::Builder
, for example.The text was updated successfully, but these errors were encountered: