[Chicago-talk] Getting new modules into the standard Perl distribution.
sean at blanton.com
Fri Jan 30 08:59:46 PST 2009
Yes, that's what we do now for some simple text modules, but supporting
a compiled module with a lot of dependencies for a broad range of Perl
versions get's trickier. You can have gcc or AIX/HP-UX/Sun compiler
versions of Perl and compiled modules are not compatible - found that
out after shipping to the customer.
Some other applications that use Perl, like msysgit and
slimserver/squeezbox ship an entire Perl distribution with the modules
they need. That seems ideal. I don't know the terms for redistributing
Strawberry Perl, but that makes it a lot more palatable than before to
include Windows in t that. The effort's a bit high to justify just right
now, just for me to use my favorite module, but maybe longer term. We
may be in a position where we have to support implementations of 5.6,
5.8 and 5.10 outside our control and more things will start breaking.
Strawberry Perl 5.8.8 also ships with a number of XML modules, so I was
wrong about that - just doesn't have my fav.
Thanks for all the input. Someone and Jon mentioned PAR's. There's some
possibilities there, too. That might be the right amount of effort for
Jeremy Wall wrote:
> On Tue, Jan 27, 2009 at 6:05 PM, Sean Blanton <sean at blanton.com
> <mailto:sean at blanton.com>> wrote:
> I am huge fan and user of the XML::Twig and Config::Properties
> modules. After all, these address handling of some of the most
> common resources found today.
> When I download Perl, however, they are not there, and the third
> most popular scripting language does not have good XML support
> "out-of-the-box". Yeah, TIMTOWTDI, but XML::Twig is the undisputed
> king of the universe imho. Add all generally accepted XML modules
> in fact - the more the better.
> The long sad story is that it is not easy for larger companies
> with standard Perl distributions to add modules. One of our
> customers has an "open source review board" where new modules need
> to be reviewed and approved and maybe tested with a number of
> different apps (most of the time it is most likely just ours).
> And, there better be a good reason to do so and it must be easy
> enough to understand and believed cost-effective for management to
> go forward with it. It's easier for them to pick up new modules on
> an upgrade. And, that is only one customer. We have hundreds.
> Can't you ship the module with your app?
> You could build and ship for the target platform if it's missing. I
> wouldn't imagine that should be too difficult. And it solves the whole
> uphill battle in getting the module into core perl. Or would packaging
> the required modules still trigger a review?
> Our product uses Perl at one layer, but we had to stop
> distributing Perl for Windows because ActiveState wanted to charge
> for it, so that ended our control. We do distribute some simple
> CPAN modules, but, that's a tricky business considering module
> dependencies and the fact we need to support Perl 5.6.x through 5.8.y
> So how are requirements managed anyway? How do I start the ball
> rolling even if it is a long uphill path and a heavy ball?
> Heading to the meeting shortly!
> Chicago-talk mailing list
> Chicago-talk at pm.org <mailto:Chicago-talk at pm.org>
> Jeremy Wall
> Jeremy at marzhillstudios.com <mailto:Jeremy at marzhillstudios.com>
> Chicago-talk mailing list
> Chicago-talk at pm.org
More information about the Chicago-talk