For example, I want to compress log files a script generates. I'm using version 5.8.8 so there isn't anything built into the core to do it. The script is cross-platform, Linux, Solaris, AIX, HPUX, and Windows.
Right now I'm thinking of using IO::Compress::Gzip. Are there any known bugs with that module? Will it work across all platforms?
To generalize a little more, how can I find out if a certain module has any known bugs, and what platforms that module will run on?
CPAN offers an array of tools you can use to determine the usefulness of a module before installing it. Unfortunately, IO::Compress::Gzip is a suboptimal example of how this can go.
When you visit the metacpan page of a module, there is a list of tools in the left column. The interesting points are
Test Results: This takes you to a page where the results of the test suite on different OSes and different perl versions are shown. Unfortunately, this service doesn't respond to my requests at the time of writing.
Bugs: This is a link to the bugtracker for this module. You can browse the list of open bugs to find possible dealbrakers. And if you find an issue, you can report it here.
Reviews: Some modules have short reviews and ratings by the Perl community. The module you mentioned doesn't have any ratings yet, so as an example, here are the ratings for List::MoreUtils.
Dependencies are listed on the right column. If you click the “dependencies” link, you can get a summary of test results for the required non-core modules for a given perl version. Unfortunately, there don't seem to be any results available currently.
Many modules also have a “bugs and limitations” section in the documentation.
Note: according to the corelist program, IO::Compress::Gzip is a core module since perl5, v9.4. This doesn't mean much: Core modules are in Core because they are needed to install other modules (or because they have historical significance … CGI, *cough*). However, this is an indication that it is reasonably stable and thoroughly cross-platform.
Related
Right now, I have my own homegrown testing harness/directory structure/support doc strucure/distribution tools for my libraries. However, reading the blog post Write your code like it's going on CPAN, it sounded like a good idea. Then it occurred to me, I'm really not sure how to do that.
What are some good resources to get started making your own Perl packages in the CPAN-like structure?
I usually start with Module::Starter. It comes with a pretty simple command-line tool that will create a new distribution from a template, including all the necessary files and a t/ directory, and so on. It will also produce either a Makefile.PL (using ExtUtils::MakeMaker) or a Build.PL (using Module::Build.)
It also places an empty .pm file there with templates in place for your POD and such.
The best place to start is the CPAN FAQ.
As noted there, the following are good resources:
perldoc perlmod
perldoc perlmodlib
As always, the PerlMonks are a good resource as well. See their "How to make a CPAN Module Distribution".
Ricardo Signes is a pretty prolific module author, and he often writes tools to make module creating as easy as possible. His modules are usually pretty up to date and he seems to stick with the most modern approaches to creating a CPAN distribution, so his distributions are probably good examples. He seems to use Dist::Zilla for managing and uploading his distributions.
Check out Module::Starter module which generates useful boilerplate to help with the creation of a modern Perl module.
Write tests! Check out the Perl Quality Assurance Projects page. It's a bit outdated, but it has some great links to quality reading material.
Check out CPANTS, the CPAN Testing Service
After you've read up on the best tools to create modules, get an account on PAUSE, which allows you to manage your distributions on the CPAN.
Join the #perl IRC chat channel on irc.perl.org. Only about half of the discussion is actually about Perl, but a lot of module authors hang out there and you can learn a lot.
See José's Guide for creating modules.
You might also like Sam Tregar's Writing Perl Modules for CPAN.
I am writing a perl program that I want to share with others, eventually via cpan. it's getting to the point where I should start thinking about this on a bigger scale.
a decade ago, I used the h2xs package maker once. is this still the most recommended way to get started? there used to be a couple of alternatives. because I am starting from scratch with very little recollection, anything simple will do at this point.
I need to read a few long text files (not perl modules) for configuration. where do I put them and how do I access them, no matter where the module is installed? (FindBin?) _DATA_ is inconvenient.
I need to provide an executable (linux and osx). can putting an executable into the user's path be part of the module installation? (how?)
I would like to be able to continue developing it, run it for test purposes, have a new version, repack it, and reupload it easily.
before uploading to cpan, can I share a cpan bundle for easy local installation to downloaders and testers?
# cpan < mybundle.cpanbundle
advice appreciated.
regards,
/iaw
If anything I say conflicts with Andy Lester, listen to him instead. He knows more than I ever will.
Module::Starter is a good, simple way to generate module scaffolding. My take is it's been the default for this sort of thing for a few years now.
For configuration/support files, I think you probably want File::ShareDir. Might be worth considering Data::Section if it's just a matter of needing multiple __DATA__ sections though.
You can certainly put scripts in the bin subdirectory of your distribution, the build tool will put it in the right place at install time.
A build tool will take care of the work-flow you describe.
Bundles are something different. You make a distribution and share the tarball/archive.
If you set up PERL5LIB appropriately, then repeat make test, make install, make dist to your heart's content. For development/sharing purposes a lot of projects do their work on github or similar - makes it easy to share. They have private accounts for business purposes too. Very useful if you want to rewind and see where/when a problem was introduced.
If you get a copy of cpanm (simple to install, fairly lightweight) then it can install from a tar.gz file or even direct from a git repository. You can also tell it to install to a local dir (local::lib compatible - another utility that's very useful).
Hopefully that's reasonably up-to-date as of 2014. You may see Dist::Zilla mentioned for module development. My understanding is that it's most useful for those with a large family of CPAN distributions to manage. Oh - if you (or other readers) aren't aware of them, do check out autodie and Try::Tiny around errors and exceptions, Moose (for a full-featured object-oriented framework) and Moo (for a smaller lightweight version).
I think that advice is all reasonably non-controversial. I find cpanm to be much more pleasant than the "full" cpan client, and Moo seems pretty popular nowadays too.
Take a look at Module::Starter and its much more capable (and complex) successor Dist::Zilla.
Whatever you do, don't use h2xs. Module::Starter was created specifically because h2xs was such an inappropriate tool for creating distributions.
It is hard for me to choose between two perl modules - Params::Validate and Params::Check.
I am writing a Mojolicious application which should be easily distributable.
Generally I mean something like uploading a directory structure on a shared hosting and be ready to run.
Params::Validate is quite powerfull and tought, has Pure-Perl implementation.
Params::Check is in the Perl Core distribution since version 5.10.0
Can you point other "why should I prefer the one or the other"?
Looking through the CPAN bug reports for each of these modules might help you to choose. Currently, Params::Check has no bug reports (it only has one wishlist item), but Params::Validate has a few. Check to see if any bug is relevant to your application.
You could also look at the CPAN Testers platform/version matrix to see if there are any fails on platforms that you would be running on.
Using the Mojo validator probably makes sense. I just want to point out that the author of Params::Validate has shifted towards Params::ValidationCompiler
For now you can use Mojolicious::Validator for validation parameters in Mojo application. http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Form-validation
I have read, at various times, both the documentation and a number of blog posts on Dist::Zilla. I have never felt confidence in my understanding of it.
In response to another question, #Ether raised the possibility of converting Crypt-SSLeay to use Dist::Zilla.
So, where can I find a concise guide showing me how to convert an existing CPAN module to use Dist::Zilla? Does the question even make sense?
Update:
The Makefile.PL for Crypt-SSLeay does a lot of work (a lot of it seems unnecessary and I am trying to prune it) to find platform specific include and lib directories, to deduce the version of OpenSSL on the machine where it is being installed. How can I include that functionality if I use Dist::Zilla?
The Dist::Zilla Choose Your Own Tutorial has a page on Converting a Dist to Dist::Zilla. One thing it doesn't mention there is my VersionFromModule plugin, which is useful if you want to replicate the way many people use MakeMaker, with the distribution taking its version number from the main module. (Many people use dzil the other way, with the version in dist.ini and a plugin to stick it into the module, but either way works.)
If I need a more complex Makefile.PL than the one dzil generates, I switch to Module::Build and use my ModuleBuild::Custom plugin, which lets me write my own Build.PL and have dzil drop in metadata like the prerequisites.
The MakeMaker::Awesome plugin lets you do something similar with Makefile.PL, but it wasn't quite what I wanted. Instead, I wrote a MakeMaker::Custom plugin that works much like my ModuleBuild::Custom plugin. The big advantage of
MakeMaker::Custom over MakeMaker::Awesome is that it makes it possible to build your dist for testing purposes without having to do dzil build. For an XS module that has to be rebuilt after every minor change, this is a big win.
These are the sites I have found the most helpful so far, as I'm in the middle of converting a CPAN distribution I comaintain to use it, as a learning exercise. I'm not there yet, but I haven't hit any super tricky bits so far!
The official Dist::Zilla site's Choose your own tutorial's guide to Converting an existing distribution
CPAN Dist::Zilla::Tutorial
Dave Golden's Why I'm using Dist::Zilla
Also, the #toolchain and #distzilla channels on irc.perl.org are full of helpful people, including the authors for Dist::Zilla and other related tools.
Is Perl a good option for writing (possibly and partially) platform independent desktop applications? I know there are interesting widget libraries like GTK2 Perl and wxWidgets but I'm not familiar with development on Windows.
Is it possible to write a good application with Perl and those tools, maybe embedding everything needed to avoid asking the user to install external (and probably non conventional for many) libraries? Are there examples of this kind of apps around?
Sort of. You can certainly write Perl scripts that provide a Tk GUI that will work on any platform, and you can even package the libraries they need to work with PAR to put together an application that will run anywhere with an appropriate version of perl installed without requiring the end use to install a bunch of stuff from CPAN to get it to work.
However, an application that will run anywhere without requiring an existing perl installation (and it's probably not safe to assume the average Windows user will have perl) isn't really viable. One solution would be to distribute an "everywhere but Windows" version that simply uses PAR to include the necessary libraries, and a PAR::Packer-built version for Windows, which would be a fully-functional .exe including the perl interpreter and the libraries.
EDIT: following daotoad's response, it does appear that ActiveState's PerlApp can build cross-platform binaries for for Windows, Mac OS X, Linux, Solaris, and AIX; I haven't tried this but if it works as advertised it would seem to meet your requirements.
My employer uses ActiveState's PerlApp to produce executable versions of our apps with great success.
We tested PAR and PerlApp before selecting our packaging method. At that time, PerlApp had faster load times. Several versions of each tool have come and gone since then, so I would recommend testing with each before selecting a tool.
Executable packaging has been very effective for us.
There are a few portability issues issues with Perl, but if you pay attention to perlport, it's easy to avoid most issues. Our biggest problems are always with Win32. From time to time, some simple thing will require stupid, bizarre work-arounds or digging into Win32 API for a platform specific hack.
We have used both Wx and Tk guis.
Frozen Bubble is a well known and widely available app you can look at.
Check out PAR (available via CPAN) with respect to your bundling requirement.
Consider having a look at Padre for an example of a complex application written in perl using Wx.
So yes. All of your requirements are achievable, including portability.
I am working on the module XUL::Gui on CPAN, which uses Firefox to display cross platform gui apps from Perl. It is under development, but stable, and may be complete enough for your needs. You can build your gui in HTML and/or XUL (the Mozilla gui language that Firefox itself is written in), and then style everything with CSS. Let me know if you have any feature requests.