in reply to common non-explicit dependencies besides LWP::Protocol::https ?

Unfortunately, there is an implicit (but common) dependency, where LWP often depends upon LWP::Protocol::https ... implicit ...

There is nothing implicit about it, its simply optional https://metacpan.org/source/ETHER/libwww-perl-6.13/Makefile.PL 

       prereqs => {
            runtime => {
                suggests => {
                    'LWP::Protocol::https' => '6.02',
                    'Authen::NTLM' => "1.02",
                    'HTTP::GHTTP' => '0',
                },
            },
        },

[download]
  • Comment on Re: common non-explicit dependencies besides LWP::Protocol::https ?
  • Download Code

Replies are listed 'Best First'.
Re^2: common non-explicit dependencies besides LWP::Protocol::https ?
by jae_63 (Beadle) on Jul 09, 2015 at 01:29 UTC
    Thanks to you all for educating me about "suggests". Now I can go back and figure out how this analysis was run, and figure out how much additional baggage would be required if I included all of the "suggested" modules.
[reply]
      You shouldn't have to include all the suggested modules. As you said, this just happened to one of your customers in the field. They probably gave a configuration that triggered it such as providing a HTTPS URL to connect to something. Your test plan may have overlooked that so there is a hole in the test plan. I'm going to assume that during your build routine, there is a scan of the code or read prepared file listing the dependencies. Sounds like you need to modify that to add the suggested ones to the top level dependencies list.
[reply]
[reply]
Re^2: common non-explicit dependencies besides LWP::Protocol::https ?
by locked_user sundialsvc4 (Abbot) on Jul 09, 2015 at 00:36 UTC

    Hmmm... if the OP says that the absence of this module caused “one of our products to break in the field,” maybe that dependency isn’t so “optional,” after all.

    I didn’t even know that dependencies could be optional.   There certainly isn’t anything intuitive about that idea, at least to me.   Out of curiosity, how do CPAN-authors determine that such a status should be assigned?   Can it be overridden?   Can dependency-checking tools be instructed to include these “optionals” in their scans?

    It sure does sound like the mechanism failed the OP and at least one of his customers.   So, what needs to be done about this?

      I didn’t even know that dependencies could be optional. There certainly isn’t anything intuitive about that idea, at least to me.

      Arguably, supporting HTTPS can, as of recently, be considered required. So, in the specific case of LWP::Protocol::https, perhaps that should now be required.

      As for "optional features" in general, perhaps a better way of handling those? I suppose one could argue that optional feature "bar" of module "Foo" should be used via module "Foo::Bar". but, going back to the OP's use of LWP, would you really want to have to call different "get" methods for different URL schemas? Or would you rather one "get" that looks at the "https:" or "ftp:" at the front of the URL and figure out which protocol to use?

      I suggest that, as an option, modules devs be able to specify "additional dependencies" as a hash of lists mapping "optional features" to the additional modules required to support said optional features. I'm not sure how best to to handle such options during module install, but having a feature/requirement map available will help with managing installed modules.

[reply]

In Section Seekers of Perl Wisdom