|
Oberon has asked for the wisdom of the Perl Monks concerning the following question:
O masters of distribution fu:
I have a module (Data::Random) that is using Module::Install. (Yes, yes, I really should upgrade it to Dist::Zilla, but I don't have time right now. I will soon, honest!)
In the meantime, I've tried to get MI to generate a META.json file. I can do this by using Module::Install::JSONMETA. (And, yes, I know that the module is deprecated because it claims it is--or soon will be--no longer necessary, but I can't seem to get the META.json file any other way.) So all that works fine, except that, apparently, something in there is requiring YAML::Tiny during installation. I'm not sure why that is. Seems to me like that should be required on my (author's) side, not on the client (installer's) side.
But, anywho, now I have a couple of open RT tickets about how it won't install if there's no YAML::Tiny on the client side, and the solution seems to be just to get YT jammed into the inc/ dir that gets bundled up with my distro. But I can't figure out how to do that.
Anybody know what I need to do here? That is, either how I can get YAML::Tiny installed into inc/, or, failing that, how I can get MI to stop requiring YT during installation, or, failing that, how I can get MI to generate a META.json without using MI::JSONMETA. TIA! |
Re: Convincing Module::Install to put stuff in inc/
by davido (Cardinal) on May 26, 2012 at 03:59 UTC
|
Do you need for it to be bundled in ./inc? Or would it be adequate to assure that when a user types cpanm Data::Random (or his favorite variation on that command), he gets YAML::Tiny pulled in prior to Makefile.PL executing? Usually that's fine. And if that's the case, you can put the following directive into your Module::Build-based Makefile.PL:
configure_requires 'YAML::Tiny' => '0.0';
That invokes ExtUtils::MakeMaker's configure_requires directive for its write_makefile function. When you make dist, the appropriate metadata will be written into META.yml so that the user's CPAN installer will pull in the configuration dependency prior to executing Makefile.PL on his own system.
If you really do need to bundle some dependency along with your distribution, have a look at the docs for the Module::Install extension/plugin: Module::Install::Bundle. I haven't used it, but it claims to be able to bundle another module into your distribution. That seems more useful for distributions that have dependencies that might not be readily available (or available in a specific version) on CPAN.
| [reply]
[d/l]
[select] |
|
|
Do you need for it to be bundled in ./inc?
Not in the least. :-)
Or would it be adequate to assure that when a user types cpanm Data::Random (or his favorite variation on that command), he gets YAML::Tiny pulled in prior to Makefile.PL executing? Usually that's fine. ...
Yes, I think that should work. I'll give it a shot and see if that fixes the problem for my bug reporters. Good tip; thanx.
If you really do need to bundle some dependency along with your distribution, have a look at the docs for the Module::Install extension/plugin: Module::Install::Bundle.
Actually, I messed around with that one already. It doesn't do what I wanted it to do ... it bundles the distribution into my distro, which then it will (theoretically, although I also found somewhere in the POD that said it didn't work) install when/after it installs mine. But, even if it did work, it wouldn't work, if you follow me. Having YAML::Tiny all bundled up doesn't do any good if the installation needs to use it.
On mst's advice, I also tried include('YAML::Tiny') in the Makefile.PL, but I got: Unknown function is found at Makefile.PL line 19. But it actually did put YAML::Tiny in inc/, so it sort of worked ... you know, with the minor disadvantage of causing my make disttest to fail. :-/
But I think the configure_requires idea should work, so I'm going to try that..
| [reply]
[d/l]
[select] |
Re: Convincing Module::Install to put stuff in inc/ (zilla--)
by tye (Sage) on May 26, 2012 at 06:11 UTC
|
(Yes, yes, I really should upgrade it to Dist::Zilla, but I don't have time right now. I will soon, honest!)
Well, that will certainly prevent several people from contributing to that module. It provides a huge barrier to even writing a patch for your module. And not being able to write a patch can even discourage just reporting a bug. (Though, some of that last part is mostly repeating what brian d foy said the other day.)
I had a one-line change to a module that I desperately wanted deployed and really, really wanted uploaded to CPAN. But Dist::Zilla is way too much work and that was very effective at preventing me from getting to either of those tasks, that would otherwise be quick work.
| [reply] |
|
|
I don't use Dist::Zilla myself, and don't have it on my machine, but I've still patched Dist::Zilla-based modules. After all, even without Dist::Zilla installed, I can still edit the modules in 'lib', can't I? I can still edit the code.
OK, so they might be using Pod::Weaver to add boilerplate headers and footers to their pod, but chances are the documentation for the functions/methods/etc is still plain old pod, and I can edit that too.
And maybe I can't generate the Makefile for make test, but I can still run prove -w -Ilib t/* xt/*, which is sufficient in most non-XS cases.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l]
[select] |
|
|
Ah, you are mostly talking to brian d foy's points. I don't have experience trying to patch a Dist::Zilla module beyond having noticed that several mundane things that I'd normally do to try to start such a process run into a lack of Dist::Zilla and effectively stopped me. Brian said something about even the module code is turned into a template. Perhaps he didn't realize that the template mostly usually doesn't impact the code? I wouldn't know as I haven't surveyed any Dist::Zilla modules on that point. I don't know how many he has vs. how many you have.
The author of a Dist::Zilla-using module that was present didn't disagree with brian's points. He even mentioned wanting to remove the Dist::Zilla dependency and not being sure even how to do that (I thought he should write a Dist::Zilla plug-in that removes the dependency for you).
Preventing others from even doing "make test" is a pretty big roadblock. Sure, for many modules you can get away with skipping the "make" step and just hope that "perl -Ilib t/blah" actually works immediately. That certainly isn't my habit or assumption. I know of at least one module of mine (not yet on CPAN) where that assumption doesn't hold. So, when somebody hits that roadblock, they might decide to dive in and figure out how they can work around having no "make test".
Thanks for noting that it often isn't hard to work-around.
| [reply] |
|
|
|
|
|
|
|
|
Ah, someone who actually doesn't like DZ ... I sorta thought it was the latest Perl darling, at least in the distro packaging arena. But I suppose there's always a contrary viewpoint.
I gotta be honest: I always felt DZ was overkill myself, and I never planned on really checking it out until I was juggling like a dozen CPAN modules at once (if I ever get there). But then I got handed a project to come up with a packaging system for $work, and even then I was going to stay away from DZ--I was tentatively planning on using a combination of ExtUtils::ModuleMaker and Module::Install--but the more I started looking at what I needed to do, the more I realized that, FTMP, DZ already did it, and so I ended up biting the bullet. Now I can't imagine doing without it.
Of course, as I say, I still haven't converted any of my modules over to use it ... it's not particularly conducive to just jumping in and getting started quickly (at least IME). But I do plan on doing so eventually. I think in the long run I'll be happier: less whining about having to keep version numbers sync'ed across multiple library files, less maintaining of my own cobbled together script for PAUSE uploads, less boilerplate copying, etc. And I think tobyink has the right of it in terms of potential contributors running tests: prove is the bomb. I use that over make test myself, most of the time.
And, of course, there's also the concept that, the more popular it becomes, the less you can avoid it. I never particularly liked Module::Build (e.g.), and in fact I spent a few months cursing its name in the early days, but there's no point trying to pretend it doesn't exist at this point: you have to learn to deal with it, that's all.
Maybe DZ will never reach that point though. Who can say?
| [reply]
[d/l]
[select] |
|
|
"less whining about having to keep version numbers sync'ed across multiple library files"
Seen perl-reversion which comes with the Perl::Version module? It makes this a breeze. (In fact, DZ uses Perl::Version to do its version-setting dirty work, so if you've got DZ on your system, you've already got perl-reversion installed!)
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply] |
|
|
|
|
But I do plan on doing so eventually. I think in the long run I'll be happier: less whining about having to keep version numbers sync'ed across multiple library files, less maintaining of my own cobbled together script for PAUSE uploads, less boilerplate copying, etc.
It sounds more like you are doing it wrong, to me. I see no point in putting the same version number into multiple library files. You don't have to use your own upload script. You can just use CPAN::Uploader which is easy to just jump right into.
I have quite a few modules on CPAN and more not there yet and I don't have anything that I consider "boiler plate". I do sometimes copy an old module when making a new module but that's one short command and just done to get the structure and then to replace 99% of it. And trying to abstract out the common skeleton would be a waste of time because it keeps evolving and there are always parts that fit some modules and not others.
So you haven't hit on a reason why I would benefit from using Dist::Zilla. But it'd have to be a pretty powerful benefit for me to invest the time to get half of CPAN installed and risk having such a huge amount of complexity behind something such that I might have to dive into that much stuff to try to diagnose when something goes wrong.
| [reply] |
|
|
|
|
Ah, someone who actually doesn't like DZ ... I sorta thought it was the latest Perl darling, at least in the distro packaging arena. But I suppose there's always a contrary viewpoint.
That number is quite larger than you might believe :) Why I hate Dist::Zilla was only posted last year. Give it another 10 years and dzil will be as popular as Module::Build ;p
| [reply] |
|
|
|
|
Re: Convincing Module::Install to put stuff in inc/
by tobyink (Canon) on May 26, 2012 at 10:25 UTC
|
$self->include_deps('YAML::Tiny', 0);
You could try patching Module::Install::JSONMETA to do this, or you could write a small Module::Install plugin of your own which pulls in the YAML::Tiny dep and does nothing else.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
Re: Convincing Module::Install to put stuff in inc/
by Anonymous Monk on May 26, 2012 at 08:45 UTC
|
Module::Install::Bundle - Bundle distributions along with your distribution | [reply] |
|
|
