On 4/4/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> I want to see File::HomeDir ultimately in there, because there's a
> number of things that use $ENV{HOME} and implement their own special
> case logic.
If it presents a platform independent way to find a home dir then I
agree with you.
> You want to add ExtUtils::Installer once it works, so
> ExtUtils::MakeMaker can use it.
Well, actually ExtUtils::Installer is not that much more than a
figment of my and Randys imagination, so I certainly havent thought
about adding it to core. But if adding it to core meant signifigant
improvements in CPAN and Module::Build's ability to install then I
would say it should go in. Thats a big hypothetical tho.
> Module::Build wants to go in, but because they use YAML for the data
> file, we add Ingy's YAML.pm, who then decides he wants to use Test::Base
> for everything he does, so that slips in undernearth, and of course
> Test::Base is based on Spiffy, so Spiffy needs to go in the core (which
> isn't what actually happened, but could have)
Actually I thought the decision was that YAML wasnt going in and that
the MB team would roll their own writer?
Anyway, MB to me underscores the issue nicely. Its a big module. Its
getting added to core. Win32API::File is a fraction of the size and
performs essential tasks that you cant do without it (including
upgrading certain key dual-lifed core modules). Both ExtUtils and MB
would benefit from it. File::Temp would benefit from it. Yet for some
reason Win32API::File cant be added. Whereas Module::Build, for all
its superiority over ExtUtils::, does basically the same thing yet its
getting added.
Going back to your example. Spiffy from what i can tell is more or
less along the line of a development luxury item. IMO luxury items
dont really belong in core. Something that uses a luxury item also
doesnt belong in core.
But infrastructure code that is essential on its platform, or code
that provides a abstraction layer over platform dependent quirks IMO
does belong in the core.
As an example I see DDS as a luxury item. For all its superiority over
DD I dont really think it belongs in core. But it contains code that I
see as infrastructure so as time permits im trying to make patches to
migrate that functionality alone to core.
OTOH, something like File::HomeDir, assuming it presents a platform
independent way to deal with the issue of "home directories" sounds to
me like it _should_ be in core. Then people will actually use it
instead of rolling their own every time they need to. Then programs
wouldnt do stupid things on my computer because i dont have an
ENV{HOME} set in my environment.
> It goes on and on and on, and eventually it's impossible to make the
> core build and smoke cleanly on any platform, because not all of these
> packages work everywhere all the time on all platforms.
As long as the modules involved are the type I mean then I dont see the problem.
To clarify: Platform specific infrastructure code, or platform
independent abstraction code belongs in core.
> The core is expected to work everywhere, just look at the number of
> File::Spec subfiles now. The work involved to deal with full(ish)
> platform support is enormous.
My view is the core doesnt actually work everywhere because its
missing essential tools on at least one of those platforms.
> Which is why although I'd secretly like to put File::HomeDir in tomorrow
> and deal with problems later, I'm not going to say a damned thing until
> I'm sure it's completly bug free and working on as many platforms as
> possible, before I even think of broaching the idea.
>
> On the other hand, if you have a specific problem domain you want to
> address, it's perfectly acceptable to build a distribution that contains
> all the extra things you need for that problem domain, without the need
> to impose the extra bloat on the core.
Well my experience is that putting platform specific modules in a
platform specific distribution does not lead to those modules being
widely used by abstraction type code. A common excuse for not doing
so is that adding the use of those modules creates dependency on
modules out of core.
Whereas from what ive seen its much easier to get people to use the
code that is in the core distribution. IE, adding support from
Win32API::File or Win32::TieRegistry is problematic whereas adding
support from Win32.pm is not.
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
