|
zork42 has asked for the wisdom of the Perl Monks concerning the following question:
Moose::Manual::MooseX#MooseX::Params::Validate says:
MooseX::Params::Validate
We have high hopes for the future of MooseX::Method::Signatures and MooseX::Declare. However, these modules, while used regularly in production by some of the more insane members of the community, are still marked alpha just in case backwards incompatible changes need to be made.
I looked around the cpan pages for these 2 modules, but nowhere could I find any mention of 'alpha' or any other development status. So...
How can you determine a CPAN module's development status?
ie alpha, beta, (RTM ?) etc
Thanks! |
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by davido (Cardinal) on Sep 05, 2013 at 18:53 UTC
|
For those authors who choose to do it this way, the following lines of code in a module will designate it as a "DEVELOPER'S RELEASE"
our $VERSION = '1.00_001'; # The underscore is the tip off.
$VERSION = eval $VERSION;
If I remember correctly how the mechanics work, the indexer sees the first version line by parsing the code itself. Then the version string is evaled to wipe away the underscore so that the number makes sense ...um... numerically.
This recommendation comes from perlmodstyle.
The effect of doing this is that the CPAN indexer won't index the tarball. It's still available for download from CPAN by specifying the path to the tarball, but the CPAN installers won't automatically install it when you just type, for example, "cpanm Module::Name". From the developer's standpoint, this is a win because the smoke testers still test the distribution. So he's able to get feedback from the smokers on multiple platforms and configurations without directly disturbing his users.
...that's if the developer uses this technique. I find it really useful for modules that are easy to break in ways that aren't obvious until a bunch of different smokers test them (Inline::CPP, and XS code, for example).
Update: I guess I forgot to finish that thought.
DEVELOPER RELEASEs are one flag from developers that the specific release is not production-ready. Aside from that, a few things I look for, in no particular order:
- Do I like the POD? The documentation is the first thing I see, and can demonstrate to me that the author has thought things through, or has just cobbled something together and thrown it up there.
- The bug RT queue; Are there longstanding bugs that haven't been addressed (and that make sense -- not all bug reports are actionable or realistic).
- The Changes, or ChangeLog file: Has activity mostly been bugfixes, or have there been a lot of sweeping changes? Do the comments in this file make me feel better or worse?
- What does the source code look like?
- How do the tests look? I mean the source code for the tests; a 100% PASS rate doesn't mean much if all that is being tested is "use_ok" (I've seen that!)
- How do the smoke test results look?
- Can I find code that depends on this module?
- Are there modern issues (such as the proliferation of Unicode) that have gone un-addressed by the module in the decade since it was written? Some modules require no adjustment as time passes. Others are sensitive to modernization issues. Those that are sensitive should be modernized.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by Your Mother (Archbishop) on Sep 05, 2013 at 17:43 UTC
|
You can't. If there is a question, asking the author is the best way to arrive at a "term" for its state. Using your own good judgement, researching usage in the wild, reading the code, etc, etc, is your best defense.
There is nothing stopping an author from treating a declared "stable," "production ready" module as alpha. It's not particularly cool but it's a FOSS world and I'd rather have everyone be free to be jerks than attempt to institute the jerk police.
Conversely it does seem that authors tend to exaggerate the alpha/beta states of things to cover their own rears and not come off as aforementioned jerks. Apparently NO WARRANTY, AT YOUR OWN RISK, etc, etc isn't enough. It's almost like repeating things in all caps makes one quickly tune things out.
| [reply] |
|
|
“I’d rather have everyone be free to be jerks than attempt to institute the jerk police.”
Ooh, that’s good ... :-D
++
| |
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by toolic (Bishop) on Sep 05, 2013 at 17:21 UTC
|
| [reply] |
|
|
| [reply] |
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by Khen1950fx (Canon) on Sep 06, 2013 at 00:02 UTC
|
Here's a simple way to get DSLIP_STATUS:
#!/usr/bin/perl -l
use strict;
use warnings;
use CPAN;
use Data::Dumper::Concise;
my $d = shift @ARGV;
my(@mods) = qw(CGI MooseX::Declare);
my (@matches) = grep(($_ eq $d), @mods);
if (@matches) {
foreach $d (CPAN::Shell->expand("Module", $d)) {
print Dumper( $d->dslip_status );
}
}
Give the script a name and run it one module at a time.
CGI comes back as registered with a hashref, but MooseX::Declare simply returns {}.
Update: condensed version
#!/usr/bin/perl -l
use strict;
use warnings;
use CPAN;
use Data::Dumper::Concise;
my $d = shift @ARGV;
foreach $d (CPAN::Shell->expand("Module", $d)) {
print Dumper( $d->dslip_status );
}
| [reply]
[d/l]
[select] |
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by zork42 (Monk) on Sep 08, 2013 at 05:48 UTC
|
Thank you everyone for your very interesting comments. :)
So in a production environment:
- core perl modules: completely safe to use
- non-core perl modules: research and judgement is required
? | [reply] |
|
|
Switch.pm was a core module for a long time and was never at all appropriate for use in Production. But I agree that a module being in core makes it more likely to be appropriate for Production use.
A module being "alpha" doesn't really mean that I should avoid using it in Production, IME. I also find it quite common for a module to have both some features that I would be comfortable using in Production and some that I would not.
The most useful metric I've found for avoiding the use of modules in Production is ETOOMUCHMAGIC. An inordinate amount of complexity being relied upon to implement a relatively simple feature is a very bad sign, IME. As is the use of even relatively small amounts of non-mundane complexity.
Non-mundane complexity (often found under the label "magic") is the worst kind because it leaks out in odd ways and interferes with other non-mundane complexity and often causes problems that don't appear at first, can be triggered or defused pretty much at random, and appear completely unrelated to their sources. You can waste huge amounts of time and effort trying to deal with such problems.
While excessive depth of mundane complexity thwarts attempts at quick resolution by the sheer volume to be searched through and the great distance that can result between the problem and its source, which can make fixing the problem impractical.
When deciding whether I want to use a module in Production or not, I usually read the source code. (Though, DBI is a good example of an exception to that; but it would take too long to try to properly explain that.)
| [reply] |
|
|
| [reply] |
|
|
|
|
| |
|
So in a meaningless-adjective environment: completely a meaningless-adjective to use or research and judgement is required
I think research and judgement is required for everything because safe and production don't mean nothing :)
| [reply] |
|
|
