Re: 6PAN (was: Half measures all round)
|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 think there is CPANTS initiative underway which may be will solve some of ]problems of the current CPAN... there was even a write-up on www.perl.com about it ...
Re: 6PAN (was: Half measures all round)
On Thu, Jun 13, 2002 at 12:00:13AM +0300, [EMAIL PROTECTED] 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), Actually I doubt that complex extensions with lots of XS/C code will get ported very quickly since the work involved may be considerable. That's one of the reasons I've put so much effort into making DBI::PurePerl a viable tool. It'll automatically give people a working Perl6 DBI (for pure-perl drivers) as soon as there's a working perl5-to-perl6 translator. Tim.
Re: 6PAN (was: Half measures all round)
For the record, you will hear no disagreement from me. I recognize that this is a HARD problem. Nonetheless, I think it's an important one, and solving it (even imperfectly, by only supporting well-defined platforms) would be a major coup. --Josh At 23:31 on 06/05/2002 BST, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go oh good, have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
Re: 6PAN (was: Half measures all round)
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. Of course there would be issues of who's providing the binaries, how they are built, how external dependencies on third-party libraries are managed, etc, but still, I think it's worth looking into. It might not be a problem that's worth solving, in the end, but I think it's one worth giving serious thought to. --Josh At 23:38 on 06/04/2002 EDT, Miko O'Sullivan [EMAIL PROTECTED] wrote: [This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying 6PAN enough to merit somebody registering 6pan.org?
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote: On 6/4/02 12:59 PM, Steve Simmons [EMAIL PROTECTED] claimed: Actually, for 6PAN I think they should have to pass. And maybe we need a bug submission setup, and status checks, and . . . OK, OK, I'll stop now. They're nice ideas, but who bells the cat? The again, if Tim O'Reilly wants to fund me I'd be happy to do it. :-) On what platform(s)? Who's going to pay for the test bed for every possible combination of perl version, OS, various libraries, etc., etc.? I think that *requiring* that all tests pass is unrealistic. Perhaps so, but I'd prefer to see this as a goal and fall short rather than set our sights lower and achieve an empty success. As for funding - well, one source has been mentioned above. Another might be the H/W vendors. Suppose we modify the proposal to have a list of systems on which the module has been known to pass (or fail) self-test? Get H/W and O/S donations from Sun, HP, etc, volunteer labor to assemble a test framework, and then let people upload. On the web page for a given 6PAN module put a pass/fail indicator for all the stuff that vendors have donated. Vendor X wants to be on the list? Let 'em donate hardware, S/W, and (maybe eventually) something towards overhead. Hmmm, we may have a good idea here...
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in response to me: Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. . . . Nah, I think it's useful to be able to upload unstable versions to 6PAN to get the widest possible audience of testers. It's a lot easier than hosting it on a web site or whatever--for both the developer and the users. . . . True, true. You've convinced me. . . . . With (potentially) many modules having the same name and multiple authors/versions, the current complexity of the perl /lib tree could increase to the third power. That gonna be very disk-intensive for every frigging perl script that runs. See my earlier framework/bundle suggestion. I don't think it's that bad, disck-access-wise. Sticking just to the disk-intensive issue for a moment -- Due to our judicious writing of modules, libraries, etc, we tend to have a lot have relatively simple (less than 1000 lines) scripts that do quite useful things for managing our network (sorry, can't talk about 'em -- proprietary software and all that sort of rot). Each tool does a direct use or require of about a half-dozen things, but our master modules and libs grab quite a few more. All in all I guestimate we're loading anywhere from 30 to 100 modules per `simple' tool run. With standard INC plus our two or three more, that's 8-10 directory trees that must be searched. The current perl module naming schema means (essentially) one probe per directory per package until the module is found. Once it's found, all is done. With the new one, we seem to have agreed that `most recent' will be used, not `first found'. That means that every tree must be probed, and probed with globs or sub-searches to match the various author, version, $RELEASE, etc stuff. Only once we know what's available can we make an intelligent `most recent' decision. At a minimum, with 10 items in INC we have a tenfold increase in number of dir reads. Then add in the checking for author, version, etc ... and we've got to either embed the author/version/release data into the file names (the horror, the horror) or open the individual modules and read the author/version/release data from each one (the horrorer, the horrorer). This very strongly argues towards indexes. My seat of the pants number say our current tools (which use DBI to access databases) spend about as 10% of their CPU and wall clock time in compilation. This is measured by deliberately running the tools with an error (bad switch) vs running it correctly and comparing the times. Go to a module/version/release seach pattern and a ten-fold minimum increase in serach time . . . and you double the tool run times. That's intolerable in our environment. I recently spent a solid month peeling 9 seconds of per-tool overhead down to 1 second, getting a documented(!) savings of 16.25 hours *per week* in our operations group. The prospect of losing that time again with perl6 is, er, not acceptable. Again, this argues towards indexes. The current perl module tree is pretty difficult for the average day to day scripter to comprehend. I'd go even further and say that it's so complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. Yes, that would help with the understanding. It would not help with the search time overhead. Disk space and RAM are cheap and getting cheaper. Think about what you mean by gigantic. Anyone who exhausts memory by running 150 different versions of the Tk module at once deserves what they get ;) On the other hand, there's no reason that shared libs couldn't be stored in a standard location and symlinked to. Yes there is: sanity! I think that's a foolish optimization. It makes things much too fragile. Stuff like that already drives me nuts in regular Unix OS/app installations. I picked Tk as my example because it *cannot* work with multiple versions of the shared libraries (the .so files, not the perl modules) simultaneously. Every window, every widget, every Ghu-knows-what down to a fairly low level must reside in the same context. If they don't, subwindows don't get managed properly, widgets from version X can't be attached to units from version Y, etc, etc. The same is almost certianly true of DBI modules, Gnome modules, and many others. The 6PAN installation tree and perl6 module builds must be able to deal with this issue. If they don't, then Larry's promise of the ability of simultaneous load is only going to apply to pure perl modules. But I don't think that's what Larry means, and I don't think it's a restriction we *have* to live with. Steve -- STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and forth three times, it is time to pick up the phone. from the 12-Step Program for email addicts, http://www.time.com/time/columnist/taylor/article/0,9565,257188,00.html
Re: 6PAN (was: Half measures all round)
On 6/5/02 2:59 PM, Steve Simmons wrote: Sticking just to the disk-intensive issue for a moment -- [...] With the new one, we seem to have agreed that `most recent' will be used, not `first found'. That means that every tree must be probed, and probed with globs or sub-searches to match the various author, version, $RELEASE, etc stuff. [...] I recently spent a solid month peeling 9 seconds of per-tool overhead down to 1 second, getting a documented(!) savings of 16.25 hours *per week* in our operations group. The prospect of losing that time again with perl6 is, er, not acceptable. Again, this argues towards indexes. More generally, I'd just call it caching. This can be done in many ways: cached flattened bundle files, traditional indexes, or even simply another module that does some (or all) of this for you, when needed, by augmenting the use implementation with its own cached information: use Module::Cache; use Foo; # subsequent uses are faster now! :) use Bar; ... There may be some bootstrapping issues, but so far everything in Perl 6 seems up for user replacement/augmentation. Why not use as well? :) The current perl module tree is pretty difficult for the average day to day scripter to comprehend. I'd go even further and say that it's so complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. Yes, that would help with the understanding. It would not help with the search time overhead. But that's fixable. It's much harder to make an inherently confusing (but fast) on-disk organization more understandable, IMO :) -John
Re: 6PAN (was: Half measures all round)
At 2:59 PM -0400 6/5/02, Steve Simmons wrote: My seat of the pants number say our current tools (which use DBI to access databases) spend about as 10% of their CPU and wall clock time in compilation. This is measured by deliberately running the tools with an error (bad switch) vs running it correctly and comparing the times. Go to a module/version/release seach pattern and a ten-fold minimum increase in serach time . . . and you double the tool run times. That's intolerable in our environment. I recently spent a solid month peeling 9 seconds of per-tool overhead down to 1 second, getting a documented(!) savings of 16.25 hours *per week* in our operations group. The prospect of losing that time again with perl6 is, er, not acceptable. Again, this argues towards indexes. Nah. It argues for precompilation and a faster engine, both of which you'll get. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 6PAN (was: Half measures all round)
At 12:55 AM -0400 6/5/02, Josh Wilmes wrote: Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. The biggest issues with binaries are relocatability (which is a problem on some OSes), build options, compiler compatibility, and size. Size is the biggest obvious problem--there are a lot of modules with C code, and object code is generally larger than the C it came from, often by an order of magnitude or two. Multiply that by the potential number of OS/compiler/perl build options and you get a number that's rather large. The rest are just complicated icing on the cake. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even Perl class: stemsystems.com/class teddy bears get drunk
Re: 6PAN (was: Half measures all round)
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go oh good, have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: 6PAN (was: Half measures all round)
For the record, you will hear no disagreement from me. I recognize that this is a HARD problem. Nonetheless, I think it's an important one, and solving it (even imperfectly, by only supporting well-defined platforms) would be a major coup. I'd like to take that even further: just supporting Win32 binaries would be a major coup. Very few windows users can compile, but a much more significant percent of Un*x users can. A few more ways to address issues of multi-platform (my favorite is at the end): - Divide and conquer: design the 6PAN so that individuals and small groups can set up their own binary specific distribution sites. One person might decide to set up a Win32 distribution site, another a Mac distribution site. They can all register on the central 6PAN server. Users can then choose which distributions they prefer in general. - Unit testing: with binaries it becomes more imperative that downloaded modules are rigourously tested. Unit tests should be distributed with modules, and download clients should have a way of saving errors and (if the user givesd permission) sending them back to the developer. - My favorite: don't do binaries. With bytecode Pure Perl makes all the more sense. I'm not saying binaries should be prohibited, but the culture should steer away from them.
Re: 6PAN (was: Half measures all round)
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
Re: 6PAN (was: Half measures all round)
On 6/4/02 9:59 AM, John Siracusa [EMAIL PROTECTED] claimed: 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). This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. Thoughts? Or has this stuff already been hashed out elsewhere and I missed it? :) One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Regard, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Re: 6PAN (was: Half measures all round)
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
Re: 6PAN (was: Half measures all round)
On 6/4/02 1:11 PM, David Wheeler wrote: On 6/4/02 9:59 AM, John Siracusa [EMAIL PROTECTED] claimed: 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). This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. Well, there are already suggested conventions for version number formats. Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping ground for modules. Let the version numbering and API anarchists use SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() in 6PAN, for better or for worse. All I'm asking for is some small meaning behind version numbering. Is that so wrong? :) Thoughts? Or has this stuff already been hashed out elsewhere and I missed it? :) One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) -John
Re: 6PAN (was: Half measures all round)
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
Re: 6PAN (was: Half measures all round)
On 6/4/02 10:21 AM, John Siracusa [EMAIL PROTECTED] claimed: Well, there are already suggested conventions for version number formats. Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping ground for modules. Let the version numbering and API anarchists use SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() in 6PAN, for better or for worse. All I'm asking for is some small meaning behind version numbering. Is that so wrong? :) Okay, I'll buy that. And I think that suggested guidelines for compatibility between version numbers would be valuable, but I wouldn't think that we should enforce it. There may be good reasons to break backward compatibility in some cases. Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) Hmmm...perhaps as a warning: All regression tests not passed. Do you still want to upload this module? That'll stop the vast majority of offenders, and those who upload anyway will be more likely to have documented changes. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
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
Re: 6PAN (was: Half measures all round)
--- Larry Wall [EMAIL PROTECTED] wrote: : : 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. : 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. Been done before: 3.1.3. Examples The following examples of font names are derived from the screen fonts shipped with the X Consortium distribution. Charter 12 pt ... -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 Charter Bold 12 pt ... -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 Charter Bold Italic 12 pt ... -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 Charter Italic 12 pt ... -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 Courier 8 pt ... -Adobe-Courier-Medium-R-Normal--8-80-75-75-M-50-ISO8859-1 Courier 10 pt ... -Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier 12 pt ... -Adobe-Courier-Medium-R-Normal--12-120-75-75-M-70-ISO8859-1 Courier 24 pt ... -Adobe-Courier-Medium-R-Normal--24-240-75-75-M-150-ISO8859-1 Courier Bold 10 pt ... -Adobe-Courier-Bold-R-Normal--10-100-75-75-M-60-ISO8859-1 Courier Bold Oblique 10 pt ... -Adobe-Courier-Bold-O-Normal--10-100-75-75-M-60-ISO8859-1 __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote: In the spirit of Simon's desire to see radical changes when appropriate, I propose the following high-level goals for 6PAN . . . 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. Larry has stated this as a goal, and in this thread on Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: 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 . . . And that's an issue that needs to be resolved -- modules are going to have to be able to test for each others state of being loaded and have some mechanisms to disambiguate and defer to each other. I won't go down the sytactic rathole of what *that* entails, just noting it as an issue. Back to John S: : 2. Module packaging, expansion, and installation only requires a working : install of Perl 6 (unless the module contains non-Perl code, such as C, 3. Module removal should be as easy as installation. Yes, yes. 1a. Modules may be use-ed in several ways (syntax ignored for now): I addressed a few of these in RFC78 and quite a few more in an as-yet unpublished rewrite of it; Larry mentioned a line or two of syntax in a recent email that's not terribly dissimilar. All the things you specify are relatively easy in the perl world. It's mapping them into filenames and directories that @INC can use that gets, er, interesting. However . . . 1b. 6PAN modules comply with an informal contract to maintain backward-compatibility within all N.MM versions, where N is constant. . . IMHO it should be a stated requirement, just as one needs a Makefile.PL. And while person's tweak is another persons incompatible blotch, we ultimately have to defer to `in the opinion of the author.' On Tue, Jun 04, 2002 at 10:11:40AM -0700, David Wheeler responds to Johns stuff above: This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. I must respectfully disagree. Perl has rules, and strict ones -- and more than just the syntax and the semantics. Anyone can *change* perls syntax, but they have to get buy-in from a fairly large and conservative community to get it incorporated into perl. Why should we not be as careful about 6PAN? We could take this a step further -- let CPAN be the perl equivelent of Sourceforge, but hold 6PAN to a higher standard. TIMTOWTDI. One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. Yes, but . . . It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Actually, for 6PAN I think they should have to pass. And maybe we need a bug submission setup, and status checks, and . . . OK, OK, I'll stop now. They're nice ideas, but who bells the cat? The again, if Tim O'Reilly wants to fund me I'd be happy to do it. :-) On Tue, Jun 04, 2002 at 01:21:26PM -0400, John Siracusa wrote on the same thread: Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) Yep, that too. Which means . . . On Tue, Jun 04, 2002 at 10:57:15AM -0700, David Wheeler wrote: On 6/4/02 10:21 AM, John Siracusa [EMAIL PROTECTED] claimed: Hmmm...perhaps as a warning: All regression tests not passed. Do you still want to upload this module? s/Do you still want to upload this module?/Upload rejected./ On Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote: : 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. Nu? If you mean used in the sense of 'use foo', that would imply all running programs would have to write some sort of usage db, or touch a global file, or a lot of other things that I don't think are going to fly. : 1c. Distinctions like alpha, beta, and stable need to be made : according to some convention (a la $VERSION...perhaps $STATUS?) Can probably burn that
Re: 6PAN (was: Half measures all round)
On 6/4/02 12:59 PM, Steve Simmons [EMAIL PROTECTED] claimed: It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Actually, for 6PAN I think they should have to pass. And maybe we need a bug submission setup, and status checks, and . . . OK, OK, I'll stop now. They're nice ideas, but who bells the cat? The again, if Tim O'Reilly wants to fund me I'd be happy to do it. :-) On what platform(s)? Who's going to pay for the test bed for every possible combination of perl version, OS, various libraries, etc., etc.? I think that *requiring* that all tests pass is unrealistic. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On 6/4/02 3:59 PM, Steve Simmons wrote: : 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. Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. An author could make a package available that was in that condition, but it shouldn't be uploaded to 6PAN. Once one has that restrition, $STATUS isn't really needed. The adventurous will upload the alpha code from the author and install it into the 6PAN tree by specifying some sort of `force' flag. Thereafter, our adventurere is on his own. Nah, I think it's useful to be able to upload unstable versions to 6PAN to get the widest possible audience of testers. It's a lot easier than hosting it on a web site or whatever--for both the developer and the users. Obviously the 6PAN shell would install latest stable by default, but interested parties could get a glimpse of the future if they wanted, and with no harm done to existing code. Also think about the ramp-up to the first stable release. Users may want to try out all the pre-stable versions because they're better than nothing, even if they understand that there I no API contract until the first stable release. On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote: The following examples of font names are derived from the screen fonts shipped with the X Consortium distribution. Charter 12 pt ... -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1 Charter Bold 12 pt ... -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1 Charter Bold Italic 12 pt ... -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1 Charter Italic 12 pt ... -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1 . . . I was about to run screaming from the room until reading the item a bit closer. No no, you should still run screaming :) My current understanding (my hope) is that just saying use foo; always gets you the latest foo. With (potentially) many modules having the same name and multiple authors/versions, the current complexity of the perl /lib tree could increase to the third power. That gonna be very disk-intensive for every frigging perl script that runs. See my earlier framework/bundle suggestion. I don't think it's that bad, disck-access-wise. The current perl module tree is pretty difficult for the average day to day scripter to comprehend. I'd go even further and say that it's so complex as to be unmanagable. Encapsulating by module would make the structure pretty easy to understand, IMO. In re putting everything for a given module into a given directory -- it's a good thought, but I foresee problems with shared libraries (.so files). With a gigantic module like the Tk:: core, you don't always want multiple copies of each shared lib for each Tk:: version. It just ain't gonna fly. Disk space and RAM are cheap and getting cheaper. Think about what you mean by gigantic. Anyone who exhausts memory by running 150 different versions of the Tk module at once deserves what they get ;) On the other hand, there's no reason that shared libs couldn't be stored in a standard location and symlinked to. Yes there is: sanity! I think that's a foolish optimization. It makes things much too fragile. Stuff like that already drives me nuts in regular Unix OS/app installations. -John
Re: 6PAN (was: Half measures all round)
[This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying 6PAN enough to merit somebody registering 6pan.org?
Re: 6PAN (was: Half measures all round)
Hmm... I like it. It took me a good 6 months before I learned how to use CPAN. I don't see how your proposal is that different from: alias cpan='perl -MCPAN -e shell' But I get the idea. Someone (well, you've inspired me now, so I) could write a perl5 equivilent, because command line is quite nice. I'll see how it flies with my next class. More comments below. On Tue, 4 Jun 2002, Miko O'Sullivan wrote: [This seems like a good time to post something that's been on my mind for some time.] Sure. It's been pretty dull around here. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. See Perl 5 (though PHP and Java far exceed it, in doohickeys) 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. Indeed. And it should be _really_ easy to install to a different source tree and have Perl use it. I want more modules on systems I don't administrate, and asking for them is a pain. The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Hmm... yeah, I think that's as easy as library root's gonna get. I like Cinstall better than Cload, though. Don't download dependencies: cpan --dep 0 load Date::EzDate So, what's the difference between --dep 2 and --dep 3? Is that depth or something? Or max number? Update all currently installed modules: cpan update * Oh, if only shells could DWIM... Naturally this would do cpan update and then every file in the current directory. To remedy this you have to do some awful thing like: cpan update \* or cpan update '*' Maybe 'all' would serve the purpose better. Update a namespace: cpan update Date::* I like that idea a lot. Get help on using cpan: cpan help Err, howsabout the GNU way... cpan --help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done We could just go with the idiomatic don't say anything unless it's bad. I've developed a taste for that. Perhaps this is better for the default and you can enable quiet through ~/.6pan. - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... What about version discrepancies? I guess that can come from the Cuses. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. Definitely. I like on-6pan mirrors better than on-client mirrors. About the name 6PAN... I mean it reads well, but does it mean anything? The, er, 6 Perl Archive Network? RCPAN? Really Comprehensive Perl Archive Network? :) Or just PAN? I got nuthin'. Luke
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 10:48:06PM -0600, Luke Palmer wrote: Hmm... I like it. It took me a good 6 months before I learned how to use CPAN. I don't see how your proposal is that different from: alias cpan='perl -MCPAN -e shell' CPAN.pm already installs a cpan program for you that's exactly that. schwern@blackrider:/usr/local/src/CPAN/CPAN-1.61$ cat cpan #!/usr/bin/perl use CPAN; shell; As for the rest of the message, this all seems to already exist, in one form or another, in the CPAN shell or CPANPLUS shell. If you want to see a better CPAN shell, don't wait for Perl 6! Help the CPANPLUS folks out now! http://cpanplus.sourceforge.net/ But I get the idea. Someone (well, you've inspired me now, so I) could write a perl5 equivilent, because command line is quite nice. I'll see how it flies with my next class. More comments below. On Tue, 4 Jun 2002, Miko O'Sullivan wrote: [This seems like a good time to post something that's been on my mind for some time.] Sure. It's been pretty dull around here. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. See Perl 5 (though PHP and Java far exceed it, in doohickeys) 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. Indeed. And it should be _really_ easy to install to a different source tree and have Perl use it. I want more modules on systems I don't administrate, and asking for them is a pain. The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Hmm... yeah, I think that's as easy as library root's gonna get. I like Cinstall better than Cload, though. snip -- This sig file temporarily out of order.
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, Luke Palmer wrote: On Tue, 4 Jun 2002, Miko O'Sullivan wrote: No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. Personally, I'd like it to: 1) work just fine without a config file, 2) if I specify one, it uses that, 3) if I don't specify one, but the default exists, it uses that 4) if it uses a config file (specified or default) it shows the full path to what it's using, so that I have a chance of detecting Trojans and typos if I'm paying attention (I don't need or want it to ask for confirmation, just show a message and maybe 'sleep 1' before continuing) - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... Having it figure out the dependencies is definitely a major plus. As to how to solve the chicken-and-egg...just provide a way to upload multiple separate modules simultaneously. Dave
