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
{{ message }}
Repository navigation
Provide a mechanism to RequireExplicitInclusion that "module X brings in module Y" so you don't have to explicitly use Y #9
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.
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[/+]on Dec 12, 2016
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[/+]on 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.
Activity
[-]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[/+][-]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[/+]klaernie commentedon Sep 13, 2024
This would also allow to solve the problem I face with SOAP::Lite - SOAP/Lite.pm has both
package SOAP::Liteandpackage SOAP::Data, and I can neitheruse SOAP::Datanor 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.