Skip to content

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

Open

Description

@petdance

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.

Activity

  1. 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
  2. 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
  3. klaernie commented on Sep 13, 2024

    @klaernie

    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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions