[lug] hyperbolic sin() {was: (not)Using CPAN}

[Tom Christiansen]

In-Reply-To: Message from Rob Nagler <nagler at bivio.biz>
   of "Wed, 21 Oct 2009 12:17:50 MDT." 
   <3a9f8bfb0910211117n1bc271bes47d9f9240220ae20 at mail.gmail.com>

Rob, I'm not sure how to trim down your message to something 
to do a point-by-point commentary on, but I don't think I need to.

It sounds like you are providing a real add-on service for your customers,
something that sits on top of the massively replicated CPAN repository
and provides quite a bit of important functionality than CPAN.pm itself
does.  This is good.  If I were dealing with customers, I'd certainly want 
a lot more than what I currently know about what CPAN.pm does, or can do.
In fact, I have, although it was long ago and far away.  Standing between
support and development (which was my job, before moving on to internal
tools and later to real-time kernels), I pressed for and got the installation
framework to support some of the things you mentioned.  I think anybody 
in that job who looked at such things would do the same.

I was starting to smell what seemed at best a misunderstanding and at worst
actively spreading some FUD or leyenda negra about CPAN. I was mostly
disagreeing with the idea that there was something inherently "wrong" with
CPAN.  I have no quibble with adding functionality above it and around it.
I don't even have a problem with changing it in a safe and sound fashion.

That said, there's more going on with it now than I've ever used.  Have
you read about the YAML bits?  I don't know whether any of the metadata
you enjoy is there.  The CPAN.pm manpage does say:

    If the "YAML" or the "YAML::Syck" module is installed a record of the
    internal state of all modules is written to disk after each step.  The
    files contain a signature of the currently running perl version for
    later perusal.

But I really don't know how rich those state data are.  I haven't looked
into it; the manpage for CPAN.pm alone is more than 2,000 lines.  I can't
blame anyone for not knowing all its ins or outs.  I don't myself.

And then there's Jos Boumans's CPANPLUS.pm module, which is a whole nother
take on matters.  Jos is pretty darned clever, so there are probably things
there I should play with.

As for conflicts between vendor packages and CPAN installations, oh gosh yes
I've certainly encountered Catch-22 problems with packaging systems fighting
it out with CPAN, where you just could not win.  I tried for a while
to have shared trees, but it just grew too complicated for me.  That's why
I have separate trees now.  All my own are shared, but the system ones,
even from getting a vendor-package, are distinct.  It was too hard otherwise.

I've also had problems with some of the ways that the Linux RPMs for Perl 
work (or rather, don't).  That's why I gave up on them, too.

Vendor stuff goes in vendor trees.  My development kits go in my trees.
If I say package install, then it goes to the vendor, whether in /opt
or /usr/local/bin/ or wherever the platform feels like.  If I say 
"perl -MCPAN -e 'install X::Y::Z' " then it does in my trees.  It's 
the only way I've been able to keep them from breaking each other.

--tom