Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism to RequireExplicitInclusion that "module X brings in module Y" so you don't have to explicitly use Y #9

Open
petdance opened this issue Dec 12, 2016 · 1 comment

Comments

@petdance
Copy link
Member

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.

@petdance 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 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
@klaernie
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants