The Future - Managing Modules

In a previous posting, I speculated that a future version of Perl could use a general mechanism to allow module management to be provided via Perl code, as opposed to some specific module management ability itself.

I continue that line of thought with a specific suggestion. How about a mechanism similar to the way "overloaded" constants work. That is not really overloading, but uses the same syntax to enable and is often needed/used when overloaded operators are present too, so it's not too far afield. This idea is similar to "overloaded" constants, but doesn't really sound like overloading. So I don't like the overload keyword here.

In an "overloaded" constant, a hook function is called to change the compiler's interpretation of what it just parsed. It is told what the compiler read (the source text), what the compiler thought it was, and context. It can return unchanged what the compiler thought it was in the first place, or can return something different.

So, how about "overloading" the argument of require in exactly the same way? The docs on require shows that the bulk of the work is locating the file, using search paths, knowing what's implied with a bareword class name, seeing if the file's already loaded, etc. Then it can call the more primitive do function with the resulting filename string.

So, how about allowing a hook to inspect the argument to require? It will be given the source text, the result of the built-in search and expansion (the filename it resolved or undef), and context to indicate whether it was a require or use, bareword or string or expression.

The hook function can, for example, return the built-in resolution unchanged except when it sees undef, in which case it locates and/or installs the module in some way, then returns the file name.

It would be good to expose the built-in logic to be called explicitly somehow, so that the function can re-call the original search process after changing @INC or adding files. Perhaps a CORE::xxx named function.

Another use would be to log what's actually used by a running program, or verifying signatures or against an approval list before loading.

It should also be possible to chain to the old function, so such logging wrappers can cooperate with other code. Perhaps the installation mechanism can return the existing hook, if any, so the new one can feel free to call that before, during, or after it's own work.

This feature, for purposes of auto-installing things, is best used in conjuction with the proposed Perl 6 feature of having implicit code included before every script. So, your copy of Perl can be set up to use a particular module manager and the scripts don't worry about it.

Anyone have similar or opposing thoughts? (anyone from p6p reading this?)

—John

Comment on The Future - Managing Modules Select or Download Code

Replies are listed 'Best First'.
Re: The Future - Managing Modules by Abigail (Deacon) on Jun 29, 2001 at 01:22 UTC
Been there, done that. The following code is available on CPAN, as the package `The::Net`. It "overloads" `require` such that you can give it an `http` or `ftp` URL, and it will fetch the module for you using `LWP`. -- Abigail package The::Net; # # $Id: Net.pm,v 1.1 2001/04/29 04:22:11 abigail Exp abigail $ # # $Log: Net.pm,v $ # Revision 1.1 2001/04/29 04:22:11 abigail # Initial revision # # use warnings 'all'; use strict; use vars qw /$VERSION/; ($VERSION) =~ q $Revision: 1.1 $ =~ /([\d.]+)/; push @INC => sub { require LWP::Simple; require IO::File; require Fcntl; my $url = pop; return unless $url =~ m{^\w+://}; my $document = LWP::Simple::get ($url) or die "Failed to fetch $ur +l: $!\n"; my $fh = IO::File -> new_tmpfile or die "Failed to create temp fil +e: $!\n"; $fh -> print ($document) or die "Failed to print: $!\n"; $fh -> seek (0, Fcntl::SEEK_SET()) or die "Failed to seek: $!\n"; $fh; }; 1; __END__ =head1 NAME The::Net -- Use the Net to fetch your required modules. =head1 SYNOPSIS use The::Net; require 'http://www.example.com/Module.pm'; =head1 DESCRIPTION By using The::Net, you enable C<require> to fetch Modules using HTTP or FTP, when given a URL as argument. =head1 REVISION HISTORY $Log: Net.pm,v $ Revision 1.1 2001/04/29 04:22:11 abigail Initial revision =head1 AUTHOR This package was written by Abigail, abigail@foad.org. =head1 COPYRIGHT and LICENSE This package is copyright 2001 by Abigail. Permission is hereby granted, free of charge, to any person obtaining +a copy of this software and associated documentation files (the "Softwar +e"), to deal in the Software without restriction, including without limitat +ion the rights to use, copy, modify, merge, publish, distribute, sublicens +e, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be include +d in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRES +S OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILIT +Y, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHAL +L THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. =cut [download]	[reply] [d/l] [select]
Managing Modules - sub ref on @INC list by John M. Dlugosz (Monsignor) on Jun 29, 2001 at 03:35 UTC
Putting a `sub` on the `@INC` list—I had no idea! It's not mentioned in perlvar, and the equivilent code shown in `require` in perlfunc doesn't behave that way at all! How long has it been able to do that, and what else might it do that isn't well known or published?	[reply] [d/l] [select]
Re: The Future - Managing Modules by dragonchild (Archbishop) on Jun 28, 2001 at 23:44 UTC
I'm confused - what benefit would this have? Just set up your @INC using `use lib` and you're fine ... right?	[reply] [d/l]
Re: Re: The Future - Managing Modules by John M. Dlugosz (Monsignor) on Jun 29, 2001 at 00:21 UTC
No, the hook could dynamically download and install locally, or copy from a network location, the files. It could also be used for things like verifying signatures, or reporting which modules and versions were actually used (before shipping). Instead of die'ing when a use fails, it could automatically grab it from CPAN. Transparant use of distributed scripts! —John	[reply]
Re{3}: The Future - Managing Modules by dragonchild (Archbishop) on Jun 29, 2001 at 00:26 UTC
Ok. Now, my question then becomes why this needs to be a Perl hook and not just a module? Damian Conway is writing the craziest modules .....	[reply]
Re{4}: The Future - Managing Modules by John M. Dlugosz (Monsignor) on Jun 29, 2001 at 00:36 UTC


Perl: the Markov chain saw
	PerlMonks