|
|
|
|
|
|
| Author |
Message |
Henry Law *nix forums addict
Joined: 29 Apr 2005
Posts: 74
|
Posted: Wed Jul 19, 2006 4:52 pm Post subject:
How to use a module's @EXPORT array to document its exported objects?
|
|
|
I have a library of modules for a Perl application which has code
running on a Windows client and on a Linux server. Code writing and
documenting is done on the client. The number of subroutines has
expanded considerably, and I'm still developing, so I'm trying to
develop a simple utility which will document which objects are exported
from each module, and its version.
I've looked on CPAN without finding anything simple that does what I
want (but I'm not convinced I searched with the right strings, so
pointers would be welcomed), so I knocked up a simple application. It
_almost_ works and I would like it if someone can help me make the last
jump.
Here's the core of my code, using a standard module so you can run it if
you need to:
#! /usr/bin/perl
use strict; use warnings;
require File::Copy;
foreach my $exported_sub (@File::Copy::EXPORT_OK) {
print "$exported_sub\n";
}
For this particular module it works fine:
| Quote: | F:\>tryit.pl
cp
mv
|
But if I run it on my Windows _development_ _client_ against one of the
_server_ modules the "require" statement croaks because the server has a
different set of Perl modules installed. I get "Can't locate xxx in
@INC (@INC contains ..." messages.
So can I get access to the @EXPORT variables from a module without
causing the "require" statement to fail because it can't load dependent
modules? Or can I suppress the "Can't locate" messages safely just for
the tool? Or is there some other way of extracting the names of the
exported objects easily?
I realise that I could work around the problem either by running the
documentation tool on the server for the server modules, or by
installing the server modules on the client where I'm running the
documentation tool. The former is inconvenient; the latter ugly and
maybe not even possible. |
|
| Back to top |
|
 |
anno4000@radom.zrz.tu-ber *nix forums beginner
Joined: 05 Jul 2006
Posts: 40
|
Posted: Wed Jul 19, 2006 7:35 pm Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
Henry Law <news@lawshouse.org> wrote in comp.lang.perl.misc:
| Quote: | ...expanded considerably, and I'm still developing, so I'm trying to
develop a simple utility which will document which objects are exported
from each module, and its version.
|
[...]
| Quote: | Here's the core of my code, using a standard module so you can run it if
you need to:
#! /usr/bin/perl
use strict; use warnings;
require File::Copy;
foreach my $exported_sub (@File::Copy::EXPORT_OK) {
print "$exported_sub\n";
}
For this particular module it works fine:
F:\>tryit.pl
cp
mv
But if I run it on my Windows _development_ _client_ against one of the
_server_ modules the "require" statement croaks because the server has a
different set of Perl modules installed. I get "Can't locate xxx in
@INC (@INC contains ..." messages.
So can I get access to the @EXPORT variables from a module without
causing the "require" statement to fail because it can't load dependent
modules? Or can I suppress the "Can't locate" messages safely just for
the tool?
|
The latter. perldoc -f eval.
Anno |
|
| Back to top |
|
 |
Henry Law *nix forums addict
Joined: 29 Apr 2005
Posts: 74
|
Posted: Wed Jul 19, 2006 8:52 pm Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
anno4000@radom.zrz.tu-berlin.de wrote:
| Quote: | Henry Law <news@lawshouse.org> wrote in comp.lang.perl.misc:
....
But if I run it on my Windows _development_ _client_ against one of the
_server_ modules the "require" statement croaks because the server has a
different set of Perl modules installed. I get "Can't locate xxx in
@INC (@INC contains ..." messages.
....
modules? Or can I suppress the "Can't locate" messages safely just for
the tool?
The latter. perldoc -f eval.
|
OK, I see the basic principle: wrap up my "require" in an eval statement
so that the program doesn't crash. But the eval still fails with the
same error (now visible in $@), and doesn't create the variables, or
make them visible.
Snippet of the code
eval {require NFB::Utilities::Server};
warn $@ if $@;
print "Version of NFB::Utilities::Server is
$NFB::Utilities::Server::VERSION\n";
The variable $NFB::Utilities::Server::VERSION (which I can see is
defined in the module) is undefined, as is the @EXPORT_OK array etc.
I must be missing something ... |
|
| Back to top |
|
 |
A. Sinan Unur *nix forums Guru
Joined: 03 Mar 2005
Posts: 1840
|
Posted: Wed Jul 19, 2006 9:54 pm Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
Henry Law <news@lawshouse.org> wrote in news:1153327933.17726.0
@proxy00.news.clara.net:
| Quote: | But if I run it on my Windows _development_ _client_ against one of
the _server_ modules the "require" statement croaks because the
server has a different set of Perl modules installed. I get "Can't
locate xxx in @INC (@INC contains ..." messages.
So can I get access to the @EXPORT variables from a module without
causing the "require" statement to fail because it can't load
dependent modules?
|
....
| Quote: | I realise that I could work around the problem
|
....
| Quote: | by installing the server modules on the client where I'm running the
documentation tool.
|
....
| Quote: | ugly and maybe not even possible.
|
I do not understand why that is ugly or impossible in most cases. It
seems to me that the development environment ought to be as similar to
the deployment environment as possible.
On the other hand, I just went to search.cpan.org, and typed:
module info
in the search box.
Among the results, there were some promising looking modules, but I
would not a priori expect them to deliver exactly the information you
need without being able to compile a module.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html |
|
| Back to top |
|
 |
anno4000@radom.zrz.tu-ber *nix forums beginner
Joined: 05 Jul 2006
Posts: 40
|
Posted: Wed Jul 19, 2006 11:30 pm Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
Henry Law <news@lawshouse.org> wrote in comp.lang.perl.misc:
| Quote: | anno4000@radom.zrz.tu-berlin.de wrote:
Henry Law <news@lawshouse.org> wrote in comp.lang.perl.misc:
...
But if I run it on my Windows _development_ _client_ against one of the
_server_ modules the "require" statement croaks because the server has a
different set of Perl modules installed. I get "Can't locate xxx in
@INC (@INC contains ..." messages.
...
modules? Or can I suppress the "Can't locate" messages safely just for
the tool?
The latter. perldoc -f eval.
OK, I see the basic principle: wrap up my "require" in an eval statement
so that the program doesn't crash. But the eval still fails with the
same error (now visible in $@), and doesn't create the variables, or
make them visible.
Snippet of the code
eval {require NFB::Utilities::Server};
warn $@ if $@;
print "Version of NFB::Utilities::Server is
$NFB::Utilities::Server::VERSION\n";
The variable $NFB::Utilities::Server::VERSION (which I can see is
defined in the module) is undefined, as is the @EXPORT_OK array etc.
I must be missing something ...
|
No, I was missing something. I missed the fact that the missing
module was called one level down, so to speak.
So, in your example above, the module NBF::Utilities::Server calls
some module Nowhere::Around and fails. Apparently you aren't free
to modify NBF::Utilities::Server, otherwise the obvious solution
would be to change it so it doesn't immediately die when
Nowhere::Around is missing.
Without changing NBF::Utilities::Server, you can try to fake that
Nowhere::Around is already loaded:
$INC{ 'Nowhere/Around.pm'} = 'fooled you';
require NBF::Utilities::Server;
That may work, but if NBF::Utilities::Server tries to use things
from Nowhere::Around during initialization you're out of luck again.
Anno |
|
| Back to top |
|
 |
Henry Law *nix forums addict
Joined: 29 Apr 2005
Posts: 74
|
Posted: Thu Jul 20, 2006 7:58 am Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
A. Sinan Unur wrote:
| Quote: | ugly and maybe not even possible.
I do not understand why that is ugly or impossible in most cases. It
seems to me that the development environment ought to be as similar to
the deployment environment as possible.
|
Well, yes in a way, but the server bits of the code I'm writing run on a
Linux server which doesn't have lots of the end-user stuff installed
(Tk, for example), and the client end (which is where I also do the code
writing and documenting) is Windows. And some of the server modules
aren't available for the ActiveState Perl environment (well, I've not
been able to find them).
| Quote: | module info
in the search box.
|
Having had two wizard-level Perl people working on the case it's clear
to me that this idea isn't going to work so I'll stop trying and find
another way.
I'll do that CPAN search. Thanks, Anno and Sinan. |
|
| Back to top |
|
 |
ks *nix forums beginner
Joined: 11 Mar 2005
Posts: 8
|
Posted: Fri Jul 21, 2006 12:02 am Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
| Quote: | Snippet of the code
eval {require NFB::Utilities::Server};
warn $@ if $@;
print "Version of NFB::Utilities::Server is
$NFB::Utilities::Server::VERSION\n";
|
can't you put the two last lines also in eval statement? if you do
that you simply won't display the version of NFB::Utilities::Server
but as i understood this is what you wanted.
so your code could look like:
eval {
require NFB::Utilities::Server;
print "Version of NFB::Utilities::Server is
$NFB::Utilities::Server::VERSION\n";
};
warn $@ if $@;
you can build one eval statement for every module which can be
installed or not. this way your script could always start and display
some needed information if required modules exist.
best regards
ks |
|
| Back to top |
|
 |
A. Sinan Unur *nix forums Guru
Joined: 03 Mar 2005
Posts: 1840
|
Posted: Fri Jul 21, 2006 1:37 am Post subject:
Re: How to use a module's @EXPORT array to document its exported objects?
|
|
|
Henry Law <news@lawshouse.org> wrote in news:1153382310.76988.0
@demeter.uk.clara.net:
| Quote: | I'll do that CPAN search. Thanks, Anno and Sinan.
|
OK. Here is something that did something somewhat meaningful in one
specific case.
D:\UseNet\clpmisc> cat My\Module.pm
package My::Module;
use Not::Here;
use Not::There::Either;
our $VERSION = 9.123;
our @EXPORT = 'this', 'that', 'and', 'other';
"EOF My\Module.pm"
D:\UseNet\clpmisc> cat my.pl
#!/usr/bin/perl
use strict;
use warnings;
use PPI;
use lib '.';
use Data::Dumper;
my @modules = qw( ./My/Module.pm );
MODULE: for my $module ( @modules ) {
my $doc = PPI::Document->new( $module );
unless ( $doc ) {
warn "Could not load '$doc': $!";
next MODULE;
}
my $export = $doc->find( \&wanted );
my $content = $export->[0]->content;
$content = ( split /=/, $content)[1];
my @exported = eval "$content";
print Dumper \@exported;
}
sub wanted {
my ($token) = $_[1];
return unless $token->isa('PPI::Statement::Variable');
return unless $token->type eq 'our';
return unless $token->variables eq '@EXPORT';
return 1;
}
__END__
D:\UseNet\clpmisc> my
$VAR1 = [
'this',
'that',
'and',
'other'
];
This is flaky. Obviously, it will miss a whole bunch of different ways
of putting things in @EXPORT. However, if the modules in which you are
interested do not contain such cases, you might be able to get some
mileage out of this.
Dunno. Hope it helps.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Mon Dec 01, 2008 7:25 pm | All times are GMT
|
|
Anime Downloads | Loans | Personal Loans | eBay | Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|