As I mentioned early, the obvious upgrade path from EU:MM, (apparently
if you don't care about 5.004 at least) is to Module::Install.
For example...
Makefile.PL
-------------------------------------------
use inc::Module::Install;
name 'File-ShareDir';
all_from 'lib/File/ShareDir.pm';
requires 'Carp' => 0;
requires 'Params::Util' => '0.07';
requires 'Class::Inspector' => '1.12';
requires 'File::Spec' => '0.80';
build_requires 'Test::More' => '0.47';
install_share;
auto_install;
WriteAll;
-------------------------------------------
which creates the following
META.yml
-------------------------------------------
no_index:
directory:
- inc
- t
generated_by: Module::Install version 0.55
distribution_type: module
version: 0.03
name: File-ShareDir
author: Adam Kennedy <[EMAIL PROTECTED]>, L<http://ali.as/>
license: perl
build_requires:
Test::More: 0.47
requires:
perl: 5.005
Params::Util: 0.07
File::Spec: 0.80
Class::Inspector: 1.12
Carp: 0
abstract: Locate per-dist and per-module shared files
------------------------------------------
As far as I can tell, it does what you want.
questions?
Adam K
Tels wrote:
Moin,
On Sunday 29 January 2006 06:37, you wrote:
Tels,
Please forgive me for being blunt, but I think it's your fault for
writing fragile META.yml creation code.
You are right for the code being fragile. (and no offense taken :)
But there was no other way I could get the license field into the META.yml
file. And as a module author I want my distribution done with the least
fuss. I really don't want to maintain Makefils and that stuff, it is
already way to complicated.
And yet I want correct and complete META.yml files. Nothing less. I don't
care whether I have to kill a Pixie of Correct Programming for that :)
(I could have made the code more robust, but I was happy that it worked at
all.)
YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of backward
compatibility is to be expected.
Yes I know. But what else should I use? Handwrap my META.yml file? That's
not my (the module authors) job!
If you were to have wrapped your
whole custom META.yml creation code in a big eval, there would not
have been a problem. Furthermore, it seems to me that you are
reinventing the wheel by adding custom META.yml code to the
Makefile.PL of every package you write instead of, say, using
Module::Build or just omitting the non-essential META.yml
customization.
I don't want to switch my entire make process over to Module::Build, that
solves a few problems (actually, I do not have any other problem with
MakeMaker except the license field in META.yml -I am a very happy
camper!) and creates others. And I deem the license field essential.
Don't touch a working solution unless it breaks. :)
The ultimate solution, of course, is that there will be a standard
way to generate proper META.yml.
It should have been there 2 years ago.
In the meantime, however, it is my
opinion that we're better off lacking META.yml than having a
proliferation of different solutions to the META.yml issues.
I disagree strongly. Every distribution should have a proper META.yml
file, filled with the proper fields. The half-baked way it is done now
(X% dont have any, y% have one missing important things etc) is certainly
a PITLB.
Just witness Graph::Dependency, it will fail when their is no META.yml
available, and what do you want me to do then? Parse Makefile.PLs?
Anybody who relies on the meta information has a really hard job with
missing information. META.yml is create in that you can extract the
information without running some code.
So, MakeMaker should be fixed to generate proper META.ymls without the
kludges nec that I needed. Of course, Schwern wills say "patches welcome"
and I am not up to patch MakeMaker :-(
(The other way would be the META.yml file for CPAN to be generated, but
that just shifts the problem and is not really a solution. The author
knows best what goes in META.yml)
Best wishes,
Tels
