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