On 6/4/02 12:22 PM, David Wheeler wrote:
> I think that if we can agree to forego backwards compatibility, we might
> also be in a better position to set up a CP6AN with much better quality
> control. All of the most important modules will be ported very quickly
> (e.g., the DBI), and a lot of the cruft will be left to die (at least from
> the Perl 6 perspective).
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! :)
In the spirit of Simon's desire to see "radical changes" when appropriate, I
propose the following high-level goals for 6PAN (yes, that's my favorite of
the bunch ;)
1. Multiple versions of the same module may be installed on a single system
with no possibility of conflicts. That means no conflicts of any kind,
whether it be in Perl code, XS-ish stuff, private shared libs, etc.
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.
3. Module removal should be as easy as installation.
I can think of many other worthy high-level goals, but these are the most
important, IMO. And number one is by far the most important to me. A few
natural extensions of it are:
1a. Modules may be "use"-ed in several ways (syntax ignored for now):
# Note "...installed on this system" is implied at the end
# of each of the following descriptions
"Use the latest stable version of module Foo" (probably the default)
"Use the latest version of module Foo"
"Use the latest stable version of module Foo 1.xx"
"Use the latest version of module Foo 1.xx"
"Use module Foo 1.2"
1b. 6PAN modules comply with an informal contract to maintain
backward-compatibility within all N.MM versions, where N is constant. In
other words, incompatible API changes are only allowed by incrementing the
"major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor
version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e.
"backward-compatible").
1c. Distinctions like "alpha", "beta", and "stable" need to be made
according to some convention (a la $VERSION...perhaps $STATUS?)
I don't think the implementation details are too hard to hash out (he says,
optimistically... ;) But to meet these goals, they have to be thought about
early on. Some of them even require hooks in the language proper (e.g.
"use/require" extensions.)
Thoughts? Or has this stuff already been hashed out elsewhere and I missed
it? :)
-John
