So what’s new?
- Follow the meta-2 phase-requirements naming.
- The ablity to recast phase-requirements.
Plus theres more
- App::Midgen v0.30 which was a refactor to support Perl 5.8.x
A Couple of other blogs that now make sense to share with you
- midgen 0.28 plus
- Flowchart showing logic for RuntimeRecommends
- An enhancement to output infile to include Installed files
- mro – MRO::Compat catch
- issue #6.
- The Catch
Food for thought, if we update our Modules, don’t we want our users to use the current version, so should we not by default do the same with others Modules. Thus we always show the current version number, regardless.
Follow the meta-2 phase-requirements naming.
All internals now follow the meta-2 phase-requirements naming as and where applicable for clarity. This rewrite has enabled midgen to do more as it now collates more info as it scans a dist.
The following table is here as a reminder only.
Meta-2 | Meta-1.x |
---|---|
RuntimeRequires | requires |
RuntimeRecommends | recommends |
TestRequires | test_requires |
TestSuggests | recommends |
DevelopeRequires | recommends |
Now some examples
The following data snippets show the use of the phase-requirements being stored by each scanner that finds a match.
- Infiles shows the following
- file found in
- version found by scanner ( use Module::Name 1.01 (); )
- scanner that found it
- phase being checked
a core module
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
nb. no version number shown as part of perl
a dual-life module
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
nb. distribution module found is is shown also.
a module
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
nb. due to the order they run in RuntimeRecommends takes precedent in the following example.
App::Midgen::Role::Eval
is an on-going development so dose not always manage to extract version, as identifying is the higher priority in the first instance.
If you want to see all the modules found use verbose output midgen -v
Suggest you consider redirecting STDERR which will take advantage of Data-Printer output.
1
|
|
The ablity to recast phase-requirements
What the F### you say is that and why do we need it!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
- look at the infile sections
- ignore 4-7 as they are t/
- 0-1 resolves to 0
so we end up with
- 0 – RuntimeRecommends ( /lib/Module/Install/Metadata.pm )
- 2 – RuntimeRequires ( /lib/Module/Install/Admin/Metadata.pm )
- 3 – RuntimeRecommends ( /lib/inc/Module/Install.pm )
thus YAML::Tiny in this case should be RuntimeRequires
re-cast RuntimeRecommends –> RuntimeRequires
So added a huristic catch, which barfs a warning, and corrects the error by redefining prereqs
- ignore t/
- ignore Perl::PrereqScanner scans if a previous exists for the same file
- if no previous re-cast to RuntimeRequires
As 2 – is from /lib/Module/Install/Admin/Metadata.pm it needs to be re-cast to RuntimeRequires
Info: re-cast module YAML::Tiny to RuntimeRequires
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
This issues was found whilst doing some reviews on Module::Install now it is under the #toolchain.
re-cast to TestRequires
Plus there is also a re-cast to TestRequires from TestSuggests.
works in a similarly way :)
__END__