Bundle::ClearCase problem/question
I maintain a suite of ClearCase-related modules located (naturally) in the ClearCase::* namespace. There are now 5 or 6 of these so I decided recently that a bundle might be convenient. I followed exactly the instructions at http://www.cpan.org/misc/cpan-faq.html#How_make_bundle to create Bundle::ClearCase and uploaded it but still, weeks later, it doesn't work. For instance: % perl -MCPAN -e "install Bundle::ClearCase" results in Warning: Cannot install Bundle::ClearCase, don't know what it is. My best guess is that bundles must be registered via this mailing list to be useable. Is that the case? If so, I'd like to ask that it be registered. If not, does anyone know another reason it should fail to work? The bundle is definitely present on CPAN, just not useable qua bundle. A little more background: while I've gone through official namespace-negotiation procedures for my general-purpose modules, I've not bothered to do so with the ClearCase ones. Since ClearCase::* already exists and is the obvious parent namespace, and since most people on this list aren't likely to either know or care enough about ClearCase minutiae to be involved in choosing the lower-level name, I've skipped that step though in some cases I've debated the name within the ClearCase community. Anyway, is it possible that a bundle doesn't work unless all its _members_ are officially registered? Seems unlikely. Thanks, David Boyce
ANNOUNCE: Argv 0.42
This is to announce a module which has actually been on CPAN for a while now:
Argv bdph Provide an OO interface to an ARGV DSB
Argv is designed to model a command line as an object for the benefit of
wrapper programs which may need to do lots of manipulation on it. I had
written such a wrapper and it ended up doing a heinous amount of shifting,
splicing, looping, mapping and grepping on @ARGV. In some cases I had to
localize @ARGV in order that Getopt:Long could operate on a copy. And all
of this had to be done differently for UNIX and Windows. The final result
was hideous, so I wrote this module in response. After instantiating an
Argv object, you can tell it to parse its options into as many user-defined
"option sets" as you wish, then recombine them in any permutation and run
them via the system, exec, and qx methods. Here's a non-real-world example
from the POD:
# A demonstration of how to use option sets in a wrapper program.
# Instantiate an object using the current @ARGV and parse its
# flags into 3 different sets, of which we'll use one for 'who'
# and another for 'uname'.
@ARGV = qw(Who -a -y foo -r);
my $who = Argv->new(@ARGV);
$who->dbglevel(1);
$who->optset(qw(UNAME FOO WHO));
$who->parseUNAME(qw(a m n p));
$who->parseFOO(qw(y=s z));
$who->parseWHO('r');
warn "got -y flag in option set FOO\n" if $who->flagFOO('y');
print Argv->new('uname', $who->optsUNAME)->qx;
$who->prog(lc $who->prog);
$who->exec(qw(WHO));
A secondary value is for Unix/Windows interoperability. The system, exec,
and qx methods automatically quote their arguments against the ^&@$ DOS
shell and provide various other conveniences in aid of spawning new
processes on either platform without a lot of special-casing. Thus, even
users with no interest in advanced manipulation of argv's may find this
module useful as a portability enhancer.
The README is at ftp://ftp.cleartool.com/pub/Argv/README, the full POD at
ftp://ftp.cleartool.com/pub/Argv/Argv.html, and the latest full package is
ftp://ftp.cleartool.com/pub/Argv/Argv-0.42.tar.gz.
And since I'm afraid it may figure in any ensuing discussions, here's a
section from the README:
A NOTE ON THE NAME
I'm aware that single-level namespaces are generally deprecated, but there
are many modern exceptions; see Memoize, Coy, and Interpolation among
others. I tried hard to fit mine into an existing namespace as well as
soliciting ideas at [EMAIL PROTECTED] But I couldn't find a natural place
by myself and no one on the modules list was able to suggest a fitting spot
either.
Considering the alternatives of putting it in a 'wrong' category just for
the sake of having one, or creating a category ghetto for it to live in all
alone, I decided there was a reasonable case for making an exception. IMHO
"Argv" is just the natural name for this module. The [EMAIL PROTECTED]
policies don't say that single-level names are forbidden, they simply have
wording to the effect that one should think long and hard before using such
a name. I'm here to say that I did think long (seven months) and hard.
Thanks in advance,
David Boyce
new module registration: Env::Path
I'm on the verge of uploading this module. It's been discussed on the module-authors list already and at this point I think the namespace choice is obvious and non-controversial but please let me know if I'm wrong. The Env:: space and category are borrowed from Env::Array, to which Env::Path bears a passing resemblance. Here's the DSLI: Env::Path adpO Advanced operations on path variables For the curious, here are links to the current state of the module (ftp://ftp.cleartool.com/pub/Misc/Env-Path-0.01.tar.gz) and its documentation rendered as HTML (http://www.cleartool.com/Env-Path.html). Please consider this an application for registration. Thanks, David Boyce
registration of ClearCase modules
I have a few modules that have been on CPAN for a long time but have been
unregistered, because they're specific to a product called ClearCase and
thus not of general interest. But I just got an email from a user
exasperated from being unable to find them and pointing out that there's a
category ("Commercial Software Interfaces") made just for this. So - I'd
like to register them in said category. Details:
ClearCase::Argv adpOClearCase-specific subclass of Argv DSB
ClearCase::CR adpOBase class for config-record analysis DSB
ClearCase::ClearPrompt RdpfWrap clearprompt in a portable way DSB
ClearCase::SyncTree bdpOSynchronize trees of CC elementsDSB
ClearCase::Wrapper RdpfGeneral-purpose wrapper for cleartool DSB
IPC::ClearTool RdpOManage bidirectional pipe to cleartool DSB
TIA,
David Boyce
>Date: Wed, 30 Aug 2000 16:49:08 +0200
>To: [EMAIL PROTECTED]
>Subject: Thanks for Childsave and ClearTool
>
>Hi David,
>
>Thanks for this interface to cleartool, it is one of the best kept
>secrets (only the CAL interface is even better hidden).
>
>One disadvantage to your distribution:
>- At Cpan search, I expected to find it at the 'commercial software
>interfaces' for the cleartool interface.
>- the general interface which childsave is, can also be a commersial
>software interface, just the general or shell one.
>- With the search tool it was not found with childsave or with
>clearcase. Only when I typed clearcase, I found it.
>
>So I expected to find childsave or the clearcase interface since that's
>what I would look for. Is it possible to update the registration at
>CPAN? Don't play hide and seek, I like to find what I need :-)
>
>CB
add_mod feature
I've seen references to this new functionality in the archives and by all accounts the URL should be http://pause.kbx.de/pause/authenquery?ACTION=add_mod (eg see http://pause.kbx.de/). But when I go there I see no such option - instead I see the same page I would without the ACTION=. Is this broken or am I doing something wrong? I've tried with Netscape 4.72, UNIX and Windows, and IE 5 with the same result so I don't think it's a client side problem. Thanks, David Boyce
