[EMAIL PROTECTED] wrote:
>> Apparently the plan is to go in the opposite direction, i.e.,
getting that
>> stuff out of the Parrot distribution and into Bundle::Parrot on CPAN.
>
> How would the naming work there?
Not exactly certain what naming you're referring to ...
> I was trying to reduce the amount of
> keying required to invoke functions, and to keep their invocation the
same
> as if they had been installed "normally". That would eliminate the need
> for any additional documentation, (other than perhaps a statement
that "if
> you install this, you will have Foo::Bing, Bar::*, and Bam::Bam
> available", or something similar).
>
Since I only became aware of the existence of Bundle::Parrot a couple of
days ago, I can't speak authoritatively (particle, your cue). But here
is my surmise.
Over the years Parrot developers have, on the one hand, wanted to take
full advantage of the functionality developed by the Perl 5 community
and found on CPAN and, on the other, to avoid piling ever more
dependencies onto Parrot. Of necessity, this means some hard choices
from time to time. Earlier this year, for example, we finally bit the
bullet and said that to build Parrot you need Perl 5.8; Perl 5.6.1 would
no longer suffice.
When it comes to non-core CPAN modules, I know of 3 different situations:
(1) They have more or less been fully included. I think Class::Struct
falls into this category (but since I don't know it that well, don't
quote me).
(2) Significant components have been included as packages under lib/.
For testing purposes, I added Parrot::IO::Capture::Mini, which holds the
key elements of CPAN distribution IO::Capture.
(3) Individual subroutines which are either directly from CPAN modules
or provide similar functionality are stuck in various places in the
Parrot distribution. This is the case with slurp_file(), which is
similar to non-core CPAN module File::Slurp and whose inappropriate
placement in Parrot::Test started this thread/RT out.
We could go in one of two directions:
(4) Either pull all the odds and ends into a Parrot::Util (fka
Parrot::YetToBeNamed) module as Andy and I originally suggested; or
(5) Rip out from the Parrot distribution all Perl 5 code which
unnecessarily replicates functionality found in well tested, non-core
CPAN modules. Place those modules in a CPAN bundle. Tell all Parrot
developers that they need that in addition to Perl 5.8 in order to
configure, build and test Parrot. This was the approach that particle
began (but didn't sufficiently publicize) and, on reflection, I think
it's the direction we should take.
To move forward, we need someone -- who very well could be you, Ms. or
Mr. Newcomer -- to:
(6) Identify all that non-Perl 5 core functionality currently stashed
away in the Perl 5 components of Parrot.
(7) Determine what parts of that functionality are not yet found in
Bundle::Parrot and add them thereto.
(8) Propose a patch to Parrot that shows what parts need deleting, what
changes need to be made in files in docs/, etc. My hunch is that a
branch in our repository would be the best way to proceed.
(9) Pester the committers/core developers to review the patch. (Now
*that's* the hard part!)
HTH
kid51
(Alan: I merged 2 RT tickets; that's why I'm replying to your post in
this thread.)
