On 6/4/02 12:34 PM, Steve Simmons wrote:
> As for CPAN . . . don't get me started. CPAN is a blessing, but has
> become a curse as well. It's contents need to be razed to the ground
> and better/more conistant rules set up for how to do installations
> into and out of the standard trees. If you think this is a bitch now,
> just wait until simultaneous per-author and per-version installation
> and invocation is allowed as Larry has promised.
Oh, so then this has been talked about before (surprise :)
> I have this horrible fear of perl module installations becoming a bowl of
> spagetti that's been run thru a blender and mixed with a packet of jello.
> Speaking as a 20+-year sysadmin, if CPAN is used for Perl6 with those new
> features and without a massive clean, I foresee a nightmare.
I'm a big fan of the "framework" abstraction as seen I Mac OS X. All the
big, ugly mess is neatly encapsulated in "atomic" directory structures whose
internals are accessed only through a well-defined (and always backwards-
compatible) API. The internal organization of these directories can change
over time, and many versions of the format may coexist, since the
manipulation API would understand them all.
Moving modules around should be as simple as moving directories around.
Similarly, removing (all versions of) a module should be as simple as "rm
-rf dirname"
Obviously I favor encapsulation-by-module, where each "module
directory/framework/whatever" contains all installed versions of that
module. I think that's a better (physical) arrangement than by-author,
by-version, or by-origin. (Those distinctions can be made in the abstract
through introspection.)
The current Perl 5 module system of physically dividing up files by type and
origin is ins?ane, IMO. We've got a single Perl 5 "module" installing files
in 10 different, widely-separated directories. That's a very inconvenient
physical layout, future fancy keep-track-of-what-I-installed-where RPM-like
facilities or no.
Arbitrary (physical) divisions are easy enough once the modules are
individually encapsulated. I dream of seeing a Perl 6 @INC path (or
equivalent) like:
/usr/local/lib/perl6/core
/usr/local/lib/perl6/site
and that's it! One directory per "place to look for modules."
-John
