Doh! Don't read email for two days and look what happens. Its like
going on vacation and leaving the iron on.
Just FYI, the main thrust of the RFC is "More Modules". All the stuff
about multiple distributions and installation options is tangental and
will be dropped (or split off into another RFC) if they're too
troublesome.
On Tue, Sep 19, 2000 at 04:08:21PM -0400, Adam Turoff wrote:
> Are you proposing something like this:
>
> Standard distribution:
> 1: Everything (core, docs, standard modules)
>
> Alternative Distribution:
> 2a: core language (+ pragmatic modules)
> 2b: standard modules
> 2c: docs (possibly split into tutorials and reference)
#1 would be the primary distribution. Definately #1. #2a..2c would
be made available, but in a slightly less obvious way. When you go to
download perl-current.tar.gz, you get #1. #2a..c wouldn't even be in
the same directory.
> That would avoid the buggy Python distribution problem. The 2a..2c
> dists should all untar into the same directory, producing the same
> set of files that the dist #1 produces.
I don't know exactly what Python's problem is, but yes. Untarring
2a..2c will equal 1 exactly (some duplication may occur). In fact, it
might make sense if that's exactly how #1 is built.
A few people have pointed out the problems of distributing docs and
such seperately. Python is one primary example of where this goes
Horribly Wrong. Many systems have no python documentation installed.
This Is Bad. While I don't believe the seperation of docs and code
should be denied, it should be Highly Discouraged. And the simplest
way to do this is to make the default distribution contain the docs
and let the user hunt a bit for the tarball without docs.
PostgreSQL is another example of a misdistribution. While the main
tarball contains everything, its distributed in the same directory as
seperate base, docs, test and support. Many people will go for the 2
meg base tarball rather than the 7 meg full tarball. As a result, PG
is often missing docs and the tests are often not run. Lesson to
learn there is to put the sub-dists (2a-c) in a subdirectory.
> > Another is to provide several different install options. "make
> > install" installs everything, as usual. "make small_install" installs
> > just the current set of modules. "make tiny_install" installs a bare
> > minimum, not even docs.
>
> How much of the problem is the size of the install vs. the size of
> the download?
Well, my general problem is I often have two or three copies of Perl
installed on my laptop. One is an optimized copy of the latest stable
one, another is a copy of the latest devel with debugging flags,
another is latest devel optimized and finally I usually have one or
two older dists around (5.004_05 and 5.005_03). This eats alot of
hard drive space on my laptop. It would be nice if I could have one
or two be full installs and the rest minimalist.
The problem of production machines vs devel machines isn't such a big
deal. Production machines generally have plenty of space and only one
copy of Perl.
> =head1 IMPLEMENTATION
>
> A permanent ad-hoc working group should be created to discuss the
> perl6 standard library as the project comes closer to shipping code.
>
> The charter should include selection criteria for adding modules
> into the core distribution, as well as design criteria for
> modules that aim to be included into the core (e.g. adhering
> to perlstyle).
Sounds like a seperate RFC. Like I said, I want to reverse some of
the philosophies that have kept things like LWP out of the core for so
long. Anything beyond that is tangental.
> Add a section on memoize to the list of modules to add, and I'll retract
> RFC 228.
Send me a patch.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
"You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it."
Tom Christiansen in <31832.969261130@chthon>
