"Would you like to install PEM support?"
Bonus points if anyone knows what that the hell that means, before I tell you that it is a question you get when installing Bundle::CPAN on Windows.
In general, install-time questions in your Makefile.PL are almost always bad if you can possibly avoid them. Specifically, you want to avoid any questions where the resulting installation is different based on the answer.
What you want to strive for is that every installation is identical. If Module::Foo on one platform is different to another platform, you can no longer just list that module as a dependency and be absolutely sure of what will be there.
Every option doubles the locations for bugs and incompatibilities to hide.
In an ideal testing world, this is the most disasterous. Every install-time yes or no question should be tested for both the yes and no case, doubling the required test vectors.
If your module needs 40 (recursive) dependencies, which contain only 12 boolean questions in total (think "feature" questions), then ideally you need to run 2**12 test iterations (which is a LOT) in order to fully cover the module.
The questions seem appropriate when your module is new, but get more and more troublesome over time. The Catalyst guys have just realised this as well, and so you can expect that some time really soon all options will be removed from the main Catalyst distribution as part of their new risk management activities.
They realised it because most people (certainly the developers) always said yes, and then they hit a bug report from someone that said no. None of the developers could replicate the problem, and quite a bit of time was wasted.
But there's another reason that you should not need to ask certain types of questions.
Let's look at the PEM question earlier. I have no idea what PEM means, but the safe option seems to be to just install it.
But what about "Would you like to modify the abbc.csv file? If you answer wrong, this could break your abbc configuration."
Now what?
In almost every situation, the answer is not to provide a better description. People inherently do not read the details. The answer is to make educated guesses for them.
If a dependency is not needed for all users, but is for more than 50%, then just install it. If you can install without it, but need another module for a small percentage of users, default to no, and consider splitting your module into a seperate Module::Foo::PAR (for example) distribution.
But the REALLY good reason is that for every module on CPAN, a dozen or more people at various operating system distributions are eventually going to have to turn your CPAN package into an operating system package.
Which means there's no chance for per-user answers. Every RedHat user is going to get the same configuration. Every FreeBSD user won't have PAR support, and every Mandrake user will end up having to install half of Gnome because someone said yes to optional Gnome support.
Or to really boil it down to something catchy, since they have a long history of breaking modules for reasons I don't understand (sorry guys)...
"Every question your module asks is one that RedHat will answer wrong"
Along similar lines, Scalar::Util provides an option in a different way. It lets you install it with only a pure-perl version.
But that pure-perl version doesn't support the weaken and isweak functions, and the test scripts will still pass! So for anything with a Scalar::Util dependency you have two state test dimension. You need to test your module with a normal Scalar::Util, and you need to test it with a version that doesn't have weaken.
And people, including me, keep getting caught by this problem because we assume Scalar::Util has weaken, except that from time to time the distribution packager for some OS will take the easy option and just use the pure-Perl version.
Task::Weaken is a distribution that aggressively negotiates (via integrated light sabre) with the user (or rather, downstream packager) to make sure they have a version of Scalar::Util that has "weaken" (and weak reference support generally).
If your module needs to use weaken, then as well as the normal Scalar::Util dependency in your (Makefile|Build.PL) you can also add Task::Weaken as a dependency and be certain that you will have an install with weaken support.
The alternative is to write your own weaken tests, but for some reason, people (Hello Redhat and Debian) keep forcing install on minor failed tests (like testing for weaken) or doing something to mean that they don't have weaken in any case.
And Task::Weaken should mean that can go in your Makefile.PL with the other dependencies, where you are actually thinking about the issue.
Re:About PAR not being available on FreeBSD
Alias on 2006-05-27T16:47:32
Other than the weaken problem itself, they were entirely notional examples with no grounding in reality whatsoever, and merely serve as examples.Re:About PAR not being available on FreeBSD
parv on 2006-05-28T03:22:16
Ah, ok then. You had me worried there as a regular user of both FreeBSD & Perl.
