On Wed, Mar 26, 2008 at 6:29 AM, Will Coleda <[EMAIL PROTECTED]> wrote: > On Wed, Mar 26, 2008 at 7:21 AM, jerry gay <[EMAIL PROTECTED]> wrote: > > > > On Tue, Mar 25, 2008 at 7:34 PM, James Keenan via RT > > <[EMAIL PROTECTED]> wrote: > > > On Fri Mar 21 19:23:13 2008, [EMAIL PROTECTED] wrote: > > > > No, and it appears not be part of Bundle::Parrot on CPAN, either. > We'll > > > > have to rectify this. > > > > > > > > > > Coke asked me to pose this question for general discussion: > > > > > > If individual languages -- as distinct from Parrot itself -- require > > > non-core modules from CPAN, should such modules go into Bundle::Parrot? > > > Should we create a Bundle::Parrot::Languages? Should we create a > > > Bundle::Parrot::SomeSpecificLanguage? > > > > > no, definitely not. languages must be self-contained. > > As the one who started this mantra, the original intent here was to > get all the configuration information out of core parrot... > > > > that means any > > modules/libraries necessary for a particular language implementation > > must be checked for by the language itself, and not by parrot. > > ...Agreed. > > > > languages/dotnet gets this right, by having its own Configure.pl. > > other languages must move to that standard. > > > Bundle::Parrot is for perl modules that are required to build and > > develop parrot core, and parrot core only. > > This is the part that I think is open for discussion. I hesitated to > add language-specific stuff to B::P, but: > > While we're bundling the languages in the repository, I think it does > make some sense for this to support the entire repository. Balkanizing > further at this stage is arguably going to make it more difficult to > get HLL developers contributing. > > Note that we already include Test::Base which is used by APL: If we do > go this route for B::P, this should be removed. > > -- > Will "Devil's Advocate" Coleda > ok. replacing "parrot core" with "parrot distro" in my earlier message puts us in agreement. however, i want to propose the following points:
configure detection for non-core parrot functionality (e.g. language-specific libraries) should be distinguished from core configuration steps somehow (visually and/or otherwise). this will help us rip out a language from the distro when it's determined that it is time to become an external language, or to go the way of the dodo. Bundle::Parrot is currently optimized for parrot developers, because the distrobution is similarly optimized. as it stands, perhaps adding HLL-specific modules to Bundle::Parrot is in line with current thinking. however, i'm not certain that Bundle::Parrot will continue to be a development-specific bundle, or whether it will become user-centric as we approach 1.0. as i see it in my head, Bundle::Parrot would become a user-specific bundle, and something else (Bundle::Parrot::Devel?) would be the development-specific module. i don't mind proliferation of bundles under the Bundle::Parrot:: namespace, so Bundle::Parrot::APL which includes Test::Base and Bundle::Parrot seems reasonable to me. i'll couch that by letting you know that i've been called loony on more than one occasion. ~jerry
