> But once we start expecting people in the real world to compile this thing 
> on their boxes in order to install perl, it would be extremely foolish to 
> make them manually download and install perl6 + parrot + icu + perl5 + 
> cpan modules 1 through 10, all from different sources.

Try building any other large system.

We don't know what this is going to look like when perl6 is done.  

One thing we can always do is create a tarball of tarballs, or a web
page that says:
    1. click _here_ to download perl 5.12.1
    2. click _here_ to download parrot 1.3
    3. click _here_ to download perl 6.0.14

we've had enough trouble with ICU, keeping it up to date, and we're
not even using it.  (And I'd wager we never use it.)

there are already existing, well known, methods for distributing all
these things.  

Maybe I'm old school, but I'd rather download 5 small or medium sized
things than one huge thing.  It also makes it a lot easier to
change/upgrade just one piece.

Why are we reinventing wheels?  Why are we shipping extra bits around?

> IMHO, the releases better include everything necessary to build the 
> application, within reason.  Consistency and simplicity counts for a lot.  
> Why create headaches we don't need?

"within reason".  Thats where we're way off right now.

> The development environment can of course be more fluid.

Ok.  So lets rip all the crap out, and in two years when it comes time
to release 1.0, we can re-think what needs to go in.

-R

Reply via email to