I'm trying to better understand what I could use CPAN::Meta::Spec
for and came across the following sentence in the spec for the key file
:
[...]to a file that contains or generates the package. It may be given as META.yml or META.json to claim a package for indexing without needing a *.pm.
This sentence reads to me like one was able to directly specify some META.*
within the config using a path to a file instead of a *.pm
. Hence using the wording it
, that clearly associates to the formerly mentioned path. Pretty much like in the following example:
provides => {
'Foo::Bar' => {
file => 'lib/Foo/Bar.pm',
version => '0.27_02'
},
'Foo::Bar2' => {
file => 'lib/Foo/Bar2.yml', <-- META.yml?
},
'Foo::Bar3' => {
file => 'lib/Foo/Bar3.json', <-- META.json?
version => '0.3'
}
So, while Foo/Bar2.pm
and Foo/Bar3.pm
might exist in the distribution, they are not defined explicitly, but implicitly using the META.*
files.
How does such a
META.*
look like, what does it contain? Only things likename
andversion
, which is what a native Perl package might provide as well? Or additional things likelicense
andkeyword
, maybe everything except dependencies?How do CPAN-clients handle such cases?
META.*
obviously isn't the Perl package itself and I don't see how it's used to generate it. So what gets actually installed in a system in the end? Is there some additional mechanism generating the package somehow?How is providing
META.*
instead of*.pm
compatible with the keyversion
and the following restriction:
[...]If the package does not have a $VERSION, this field must be omitted.
Does META.*
count as a package containing $VERSION
in this case? Or is it expected that somehow the package gets generated in the end and that simply must have $VERSION
as well and as long as the package isn't generated, the version of META.*
can simply be used?
Thanks for your clarification!