develooper Front page | perl.perl6.language | Postings from February 2001

Re: Auto-install (was autoloaded...)

Thread Previous | Thread Next
Filipe Brandenburger
February 10, 2001 10:28
Re: Auto-install (was autoloaded...)
Message ID:
Jarkko Hietaniemi wrote:
> On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
> > Jarkko Hietaniemi wrote:
> > > Whatever we do I would much prefer being package format agnostic
> > > instead of tying ourselves too tightly with some single format.
> > Any ideas on how to do that? Without breaking requirements?
> There isn't a software problem another abstraction layer can't fix...
> Design and implement a package format independent API that has calls
> like %files = $package->getfiles(), $package->getfile($file),
> $package->gettotalsize(), $package->dependencies(),
> $package->install(), $package->uninstall(), and at lower levels
> (non-casual-user) calls like guessformat($file).  Yes, this would be
> harder than sticking with one format, but so much more flexible.
> An API and its implementation would be very beneficial also in
> installing other software than just Perl.

I agree that Archive::XYZ should all share the same interface (see threads
about interfaces), and `par' and `pun' tools could probably `plug' to one of
them and use them.

Only I'm relutant to add another 100KB to Perl distribution to include
Archive::Zip, Archive::Tar, Archive::Tgz, Archive::MacBin, Archive::Hqx,
Archive::Rpm. Not to mention maintain all these modules. Modules that ship
with Perl should be stable and high quality, and I don't think it's worth
having all them made and tested before releasing Perl 6.0.0. The less work
we have to ship it, the better it is.

Another issue is culture. Current modules are mostly all deployed in .tar.gz
format (see in CPAN if you can find some that aren't, there probably are,
but they are minorities). And not because .tar.gz is superior to others, but
because when MakeMaker was first made it had to package them someway.
Tar/Gzip got there probably because of convenience. Now we have the big
chance to choose one by features instead.

> > problems (like `oh! I don't have bzip2 and the developper only supplied
> > bzip2 version of the archive', or `oh! I'll have to do zip, tgz, bzip2,
> > whatever3 versions of the same thing only to satisfy users that use
> > different formats').
> And how is this different from 'oh! I don't have unzip'?

Zlib (handles .zip, right?) and Archive::Zip would be included with Perl
distribution. Doing it for one format is good, doing for all of them is
certainly trouble.

> > I think we should go for `standard' rather than `flexible' on this one.
> As I said on this I disagree.
> I have no problem with in the first implementation round doing just zip:
> what I abhor is the idea of hardwiring the zip assumption deeply intoour

Won't be hardwired, only will be default. Other archive formats will be
supported by having the same interface for Archive::*.

- Branden

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About