Lusercop wrote: > > On Thu, Oct 10, 2002 at 10:26:41AM -0500, Nigel Hamilton wrote: > > Because the namespace resolves to directories and files ... loading and > > pre-requisite checking can be automated ... in the case of Perl the > > namespace can't be guaranteed in the same way as Java ... > > This is an interesting issue, but not quite what I was getting at.
Heh. I'll set that as an autoreply for mail on london.pm, it'd be appropriate ~95% of the time ;) > ... If I > have a machine with only an intermittent network connection, for example, > or that has no direct net access, then downloading multiple packages can > be a hassle. I want to get all the distribution tarballs, and then in > each case install that one separately. Now, I know that often it would be > insane not to install a lot of this stuff onto a non-net-connected PC, but > I can see very good reasons why I might want a PC that is never connected > to anything, and having a full CPAN archive is unlikely to be the right > answer. > > Also, a comment raised by a co-worker (also on this list) ... Careful, that "-" is in the wrong place ;) > ... is that there is > also the problem of version incompatibility as code gets changed. This is > far more of an issue. That's the killer, in my opinion. The sysadmin problem - "arg, I've got to download 50 packages and install them in the right order" - is donkeywork, can be automated, and largely _is_ automated by the CPAN shell. If you have no network, you go in with a pile of CPAN tarballs, and a moderately trivial script iterates over them going "make, make test, make install" etc. No rocket science involved. Where the rocket science comes in is in the testing/auditing bit. Bugs here can be dependent on versions in horribly oblique ways, which suggests that you want very watertight version control (same modules on box X as on box Y). This then complicates things when you need to upgrade a certain module. Fortunately, the bug stuff is a secondary line of defence. Modules which are not written by muppets, and which have not grown horribly complicated, tend strongly to be backwardly-compatible. Paul Makepeace froths "just use a frickin' module...". What I tend to froth at is modules which increase complexity without being robust. CGI is horribly complex these days, and in an effort to make things work, at times writes to Apache directly rather than returning a string like the documentation says it does... Apache::Session's MySQL locking, by default, will wait forever. CPAN desperately needs some "Which? module" information. Is this module live? Has it been used in a production environment, and held up? MBM raises the issue of auditing, which perhaps is a new reason not to use a big, complex module to solve a small problem. > I don't think the answer is as easy as "use a module" and I don't think it's > as easy as "rewrite it every time". 1. An adequately general-purpose tool may turn into a language (like Perl). Or else become a high albedo pachyderm of some kind. A screwdriver is a bettter screwdriver than a Swiss Army Knife is. You can be too general. 2. Have several levels of reusable code. Some reusable stuff will need installing on the machine(s) in question. Building in the appropriate version at build/release time may help prevent problems with version-incompatibility ... 3. Don't cause bugs. Be backwardly compatible, where possible. Be predictable. Don't overcomplicate stuff for the hell of it. 4. When using CPAN modules whose interfaces may change, be ready to wrap said interfaces. 5. Mileage may vary. These measures are appropriate for large systems; smaller systems may not need them. etc Cheers Ti'
