On Tue, 4 Jun 2002, John Siracusa wrote: : 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! :)
I haven't gotten to that Apocalypse yet. :-) : 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. Yes, I'm already on record that multiple installed versions will coexist peacably, certainly on disk, and to the extent that they can in memory. We can't stop two versions of a module from fighting over a shared resource, for instance. Two different database modules may have to figure out who really has the connection to the database engine, and who just thinks they have the connection. Possibly it would help to have package variables that are explicitly shared among different versions of the same package when they represent a shared object. : 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... : 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. : 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" Yes, there have to be ways of getting at modules by their long names, their short names, and various intermediate wildcard names. Perl 6 will have to keep track of which version you used, so when you use the short name, it knows which long name you really mean. : 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"). Fine. We can separate out interface from implementation better in the language too. : 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. : 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.) Those are details, the like of which would be easy to determine at the last moment. But the underlying mechanisms have to be design in, yes. : Thoughts? Or has this stuff already been hashed out elsewhere and I missed : it? :) It's here and there. Some of it has been in my speeches, and some in the Apocalypses. Larry
