On 6/4/02 1:26 PM, Larry Wall wrote: > : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of > : this effort? Do we even have a vague idea of the requirements? Or does > : everyone think CPAN (and module distribution/installation in general) as it > : exists now it pretty much okay, and just needs some tweaks to work with Perl > : 6 code? I really hope that's not the case! :) > > I haven't gotten to that Apocalypse yet. :-)
Is this where I get scared by the reference to the year "2017" later in your message? ;) > : 2. Module packaging, expansion, and installation only requires a working > : install of Perl 6 (unless the module contains non-Perl code, such as C, > : etc., in which case the appropriate tools for C builds need to be present: > : cc/gcc, ld, make, and so on). Requiring "make" and friends to install pure > : perl files is a legacy relic, IMO. > > Certainly, though it's trivially easy to come up with something that's even > uglier than make. Been done many times... I'm not really concerned about the syntax so much as the dependency on "something other than Perl" for simple modules. Along similar lines, platform-specific binary distributions should probably be an (automatically-generated during submission?) first class citizen in 6PAN for systems that don't have "anything but Perl" on them (no compiler, no make, no nothing) but still want to be able to install any 6PAN module... or, heck, for people who just don't want to be bothered with compiling. I guess there are OS/library version issues there, but I think you could hit 90% of the "common" target environments pretty easily, and it should be extensible to cover more exotic targets down the road (which is why it should be an automatic part of 6PAN and not manual :) > : 3. Module removal should be as easy as installation. > > Fine. There ought to be something in the metadata that says, "This version > of this module hasn't been used since 2017." Then you can clear out the > deadwood easily. Course, disk space will be a little cheaper by then, so > maybe we'll just hang onto everything forever. Obviously you meant to type "holographic cube" ;) > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made > : according to some convention (a la $VERSION...perhaps $STATUS?) > > Can probably burn that bridge when we get to it. Well, to have use/require/etc. Support the "get me the latest-stable installed version" semantics as the default meaning, won't we need some standard way to define "stable" right off the bat? Or does "right off the bat" == "when we get to it"? Or does the absence of any $STATUS-like variable imply "stable"? (That last one seems Wall-ish, if not Perlish ;) -John
