Skip Menu |

This queue is for tickets about the Dist-Zilla-Plugin-DynamicPrereqs CPAN distribution.

Report information
The Basics
Id: 102280
Status: resolved
Priority: 0/
Queue: Dist-Zilla-Plugin-DynamicPrereqs

People
Owner: ether [...] cpan.org
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.010-TRIAL
Fixed in: 0.011



Subject: Enhancement Request: has_module, a static alternative to can_use

there's some modules that exist I'm phobic of actually loading in Makefile.PL.

For instance, I'm very glad Devel::Cover dosn't bootstrap its XS code while its sourcing, and instead bootstraps in `import`, or loading that *would* be a potentailly code-breaking thing to do.

So it makes sense to me that we have a way to statically determine if a module is installed, in the same way EUMM itself does, instead of simply loading the module into memory.

I'd probably propose something like

   has_module("Foo") 

   has_module("Foo", "1.00") # 1 if Foo exists and $Foo::VERSION >= 1.000

  has_module("Foo","<=","1.00") #  1 if Foo exists and $Foo::VERSION <= 1.00
 

Or something. That last one raises some logic issues that need to be nutted out, because somebody may want

 

  - not has foo => no problem

  - has foo > 1.00 => no problem

  - has foo and foo <= 1.00 => problem


So the state map is  .....

{ x_exists => 0/1 , x_version_range_satisfied => 0/1 }

 

Might be smart to split it into 2 functions.

if( has_module("Foo") && module_version("Foo") lt "1.00" ){  print "Error" }

if( has_module("Foo") && module_version("Foo') gt "1.00" ) { print "Standard Prereq detection OK" }

if ( !has_module("Foo") || module_version("Foo") gt "1.00" )  { "This is a satisfactory condition" } else {
    print "Error"
}

Or something?

 

> module_version("Foo") lt "1.00"

These semantics are the only place I get really scared because it implies externally dealing with version.pm stuff.

 

So ideally it would be module_version("Foo","<=","1.00")  # and you'd just transmute the <= and version bits into the right value internally and then use version.pm in whatever the right way is this week, as opposed to having everyone remember how that shit works.

 

I think -- for now -- this is a YAGNI item, given the existence of MM->parse_version($module). I'll add a note in documentation referencing its existence, since it doesn't seem to be easy to find in the EUMM documentation.

On 2015-02-23 06:55:54, ETHER wrote:
> I think -- for now -- this is a YAGNI item, given the existence of MM-
> >parse_version($module). I'll add a note in documentation referencing
> its existence, since it doesn't seem to be easy to find in the EUMM
> documentation.

Also, MM->parse_version($path), not module. Path resolution must be done first.


MM->_installed_file_for_module($module)  can be used here.


https://metacpan.org/source/BINGOS/ExtUtils-MakeMaker-7.04/lib/ExtUtils/MakeMaker.pm#L787

On 2015-02-23 16:26:32, KENTNL wrote:
>
> Also, MM->parse_version($path), not module. Path resolution must be
> done first.
>
>
> MM->_installed_file_for_module($module) can be used here.
>
>
> https://metacpan.org/source/BINGOS/ExtUtils-MakeMaker-
> 7.04/lib/ExtUtils/MakeMaker.pm#L787

I'm re-opening this request because I've discovered hand-coding this is way more complex than it needs be.

I had stitched something together with _installed_file_for_module and parse_verison, ( Which I need, because "can_use" false-negatives because module croaks on require ), but then discovered on my out-of-the-box 5.8 test fails because the EUMM on 5.8 *doesnt have* an _installed_file_for_module method.

==> Doing this by hand is way more fraught with problems than it should be and a unified just-works solution people can portably use needs to exist.
 

Implemented in version 0.011!