Hi Jonathan, in principle, you are completely right! And yet, in this case you are wrong!
I also do not want my users to have to answer questions; neither do I want to have to myself. BUT: Date::Calc used to be a high-performance module, based on a C library. Now Date::Calc isn't anymore, it is a wrapper and normally comes with a pure-Perl implementation plug-in (Date::Calc::PP). If you want to have the fast module that it used to be, you now have to install Date::Calc::XS on top, in an additional step. And I wanted the "optional requirement" in Date::Calc to notify users that installing Date::Calc::XS was strongly recommended (if you can, i.e., if you have a C compiler on your machine). Moreover, for reasons of backward compatibility with earlier Perl versions (5.005_03 and older, for instance), Date::Calc comes with a requirement for Carp::Clan 5.3 (which runs on these older Perl platforms). Carp::Clan 6.02 actually also works on Perl 5.005_03, but the tests don't pass, because they need Test::More, which requires Perl 5.6. However, whenever you can, it is recommended to install Carp::Clan 6.02, which has a bugfix that Carp::Clan 5.3 doesn't. It's not that Carp::Clan 5.3 would not work, it's just that its output is uglier than it should be. Again, I would like to notify the users that although only Carp::Clan 5.3 is required, version 6.02 is actually recommended. You see? No answering questions, just informing the users of some important changes! Cheers, Steffen 2009/10/17 Jonathan Rockway <[email protected]> > * On Fri, Oct 16 2009, O. STeffen BEYer wrote: > > Any hints on all that? > > Wow, a lot of people CC'd on that message. That is probably Considered > Annoying to the people you sent it directly to. > > Anyway, optional requirements probably aren't the *worst idea ever > conceived*, but they are close. When your module depends on optional > modules, my module can't just say, "requires Foo::Bar", it has to say > "requires Foo::Bar" and whatever modules one would need to make your > optional features work. This may change from version to version, making > it impossible to ship a reliable module that depends on yours. > > It is also a problem when communicating with others; when I ask someone > to "try Foo::Bar", I now need to tell them exactly which combination of > optional modules to install also. If I can remember. > > Finally, detecting which features to enable at runtime can be flaky. > Imagine you have a module that enables an optional feature when > Foo::Quux is installed. I don't want that feature when I install the > module, so I skip installing the prereq. For a while, your module works > fine. Some time in the future, I install Foo::Quux to satisfy the > dependencies for Gorchify::It, and suddenly, your module stops working > due to auto-detecting Foo::Quux, enabling an optional feature, and then > not working the same way anymore. Very bad. Modules should not work > differently based on whether or not other random modules happen to be in > @INC. > > The solution is to make each optional feature a separate distribution; > then it's easy to depend on the optional feature, easy to remove if you > don't want it, and easy to communicate to others. > > Also, I can tell you one thing that nobody wants to do while installing > CPAN modules, and that's answer questions. I want to say "cpan Foo" and > go away and not monitor the terminal it's running in to see if it's > asking me questions like "Do you want to install the module that you > requested to install? [y]". No... I don't want to install the module I > just invoked "cpan -i" on... thanks for asking... > > To summarize: Optional requirements considered harmful. > > Regards, > Jonathan Rockway > > -- > print just => another => perl => hacker => if $,=$" >
