2

I have a module I'd like to release to CPAN, and I like using dzil to do the packaging and releasing. However, the module relies on an external application, and while I know where it is installed on my machine, I'd like to ask users to input where it is installed on their machine. Having read Prompt user during unit test in Perl I see ExtUtils::MakeMaker::prompt does just what I want to do.

How would I incorporate that (or something similar) when using dzil?

Community
  • 1
  • 1
Robbie B
  • 63
  • 4

3 Answers3

2

The standard MakeMaker dzil plugin has no support for anything but a basic Makefile.PL. (Well, it can use File::ShareDir::Install, but that's its limit.) If you need more complex install-time behavior, you'll need to use something else.

I recommend my MakeMaker::Custom plugin. You write your own Makefile.PL, which can do anything that ExtUtils::MakeMaker is capable of, including prompt for information. You can still have dzil add things like your prerequisites at dzil build time, so you can still use AutoPrereqs. (Actually, I recommend ModuleBuild::Custom instead, but if you want to stick with MakeMaker, that's ok.)

Note: You should also allow the information you're prompting for to be supplied on the command line. This will help people who are trying to package your distribution using automated build tools. But that's a MakeMaker issue, not a Dist::Zilla one.

cjm
  • 61,471
  • 9
  • 126
  • 175
  • Thanks - this is very helpful and got me pointed in the right direction: looks like my weekend is going to be a fun one! – Robbie B Sep 26 '12 at 09:56
0

The user should not be installing via Dist::Zilla at all. It is an author-tool only, as its documentation explicitly says. Dist::Zilla is meant to build a distribution that is installed via EUMM or M::B.

Edit: Given your comment, I would instead say, it sounds like your build process isn't a good candidate for using Dist::Zilla, at least consistently. I would suggest using it to build it once more and then move to using the EUMM or M::B that it builds, modify it to your purposes and keep developing that.

Joel Berger
  • 20,180
  • 5
  • 49
  • 104
  • I'm building the release with dzil. The user is not using it to install the package. – Robbie B Sep 24 '12 at 14:34
  • Generating a Makefile.PL is probably the _least_ important thing dzil does for you. Automating the release process (so you don't make stupid mistakes like forgetting to run the tests before uploading) is a much bigger deal. – cjm Sep 26 '12 at 17:39
0

If you're using ExtUtil::MakeMaker to install your distribution, then you can use the dzil plugin Dist::Zilla::Plugin::MakeMaker::Runner (that's a mouthful) to bundle a custom Makefile.PL with your dist instead of generating the default one.

That will allow you to use prompt to gather custom information from within the Makefile.PL if you need it.

friedo
  • 65,762
  • 16
  • 114
  • 184
  • ok, so its possible, but isn't this rather "gone 'round the bend"? If you can no longer use the autogenerated Makefile.PL, doesn't it just seem simplest to use the standard tools then, rather than (not-)auto-generate them? – Joel Berger Sep 24 '12 at 15:04
  • I don't think so. I currently maintain a dist that has some custom stuff in its Makefile.PL and converted it to Dist::Zilla anyway to take advantage of all the rest that dzil offers, like perlbrew testing, git integration, PodWeaver generation, and so on. – friedo Sep 24 '12 at 15:08
  • If you do make use of those features, then perhaps you are right. I didn't and so I moved away from dzil back to M::B. TIMTOWTDI of course :-) – Joel Berger Sep 24 '12 at 15:18
  • 1
    Instead of MakeMaker::Runner, I recommend using my [MakeMaker::Custom](https://metacpan.org/module/Dist::Zilla::Plugin::MakeMaker::Custom) plugin. This lets you get your prerequisites from dzil. – cjm Sep 24 '12 at 21:59