Hello Aristotle,

I'll answer below:

2009/11/3 Aristotle Pagaltzis <pagalt...@gmx.de>

> * O. STeffen BEYer <ost...@gmail.com> [2009-10-13 15:30]:
> > I'd rather have the user decide what he/she wants, as in this attached
> file.
>
> That’s the wrong way to think about it.
>
> OK, hyperbole; it’s not *wrong*. But it’s very incomplete.
>
> Don’t forget that there are a lot of people who might merely want
> to use some Perl program, and unlike you and me, they *aren’t*
> Perl programmers. They are merely users of some random Perl code
> that uses your module. Most of these users don’t care which
> version of your module gets installed, and if you ask them to
> pick one anyway, they won’t know how to decide, either. All they
> know is they want the program they care about to work.
>
> To these people, the option you want to offer is not helpful. It
> is, in fact, a bewildering obstacle.
>

Yes, I agree.
This is one of the reasons why I have adopted the common approach
of Date::Calc being the pure Perl module, and Date::Calc::XS the
plug-in needing a C compiler.
Another reason was that you would not know which version had
been tested in CPAN::Testers.
And still another reason was that when giving support, it would
be extremely hard to find out which version the user was using.
I would have needed the user to jump through hoops to get this
information.

So for them, you have to provide sensible defaults for all
> options. (And if there isn’t any strong reason to offer an option
>

That was actually the case (or is - see version 6.1 of Date::Calc!).
The presence of a suitable compiler was determined, and then
Makefile.PL explicitly said what was recommended. By just hitting
Return, the user would get the recommended option.


> in the first place, it shouldn’t even be an option. But that’s
> just a sidenote, since in your case there is solid reason.) That
> means your module should just check for a compiler and install
> with the XS variant by default if possible. The option to change
> that should be provided in such a way that opinionated users can
> get at it without forcing other users to care. (This is probably
> best achieved by checking some environment variable in your *.PL,
> since that passes down easily through the CPAN shell, whereas
> taking a switch would force more manual monkeying.)
>
>
> * O. STeffen BEYer <ost...@gmail.com> [2009-10-13 23:05]:
> > Since Date::Calc is such a low-level basic module, it should be
> > especially backward compatible, so that even people in old
> > production environments (never fix what ain't broken) can
> > upgrade my module and benefit from new functions, without
> > having to install a load of other modules first - which their
> > company policies would probably not permit.
>
> If they can install Date::Calc, how come they can’t or won’t
> install other modules? OK, maybe they can’t install XS modules.
> I can see that. But if they can install *your* pure-Perl module,
> why can’t they install other pure-Perl modules also?
>
> This is not the first time I see this argument and I never
> understood it. *headscratch*
>

Sometimes they can get permission for one module, or at least a well-defined
list of a few modules,
but not for an endless list of modules and dependencies (which the user
frequently does not know exactly
in advance). And "permission" does not mean that they can install the
module(s) themselves,
no, it means that the administrator is going to install the module(s) for
them. So the less work
this administrator has to do, the more likely to get his/her permission (if
he/she has the power
to decide that, as is sometimes the case in certain companies). And it may
be even more difficult
to get permission from a manager who hasn't a clue what the user is talking
about, and the less
the manager sees a security risk, the better. So the fewer modules, the
better.

Do you understand it now? :-)

Best regards,
Steffen

Reply via email to