Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc

by zork42 (Monk)
on Sep 05, 2013 at 16:56 UTC ( #1052605=perlquestion: print w/ replies, xml ) Need Help??
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!

Comment on How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by toolic (Chancellor) on Sep 05, 2013 at 17:21 UTC

      And it was an old idea that never really delivered the value and so it is mostly ignored (IME) and so is extremely likely to be very out-of-date. On average, I expect it to be worse than useless.

      - tye        

Re: How can you determine a CPAN module's development status? ie alpha, beta, (RTM ?) etc
by Your Mother (Canon) 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.

      “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 davido (Archbishop) 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.

    Dave

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 ); }

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
    ?

      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 :)

      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.)

      - tye        

        ... ETOOMUCHMAGIC ... Non-mundane ... smell

        Hmm, what's that mean?

        Re: Can an element be created because it was accessed ? ( || {} )
        autovivification.pm; Yes, it sticks its fingers way too deep into guts...strong smell of ETOOMUCHMAGIC
        Practical example of "Is Perl code maintainable"
        Note that I didn't use File::stat because the BUGS section is unacceptable to me. ETOOMUCHMAGIC is such a common problem
        (tye)Re: Reading a pipe
        a bug in antique perl version, nothing interesting here
        Is Devel::Declare really so much less evil than source filters?
        said "weird issues that won't seem to make any sense". Those both smell very much like ETOOMUCHMAGIC.
        ETOOMUCHMAGIC breakage can be quite cryptic and fundamental and might not even hint at the module that is pumping in the most "magic". So you waste a lot of time trying to find the source(s) of the problem.
        Hello, three years have passed. What happened between D::D and the p5p? How did D::D evolve?
        Too much black magic
        Sub::Uplevel
        Re^10: Scalar context of slice (vs grep)
        ETOOMUCHMAGIC -- assuming things that do not remain true -- an explanation given that included unnecessary complication and that complication also had the distinct disadvantage of having lead other people into problems -- quoted meme is seriously flawed
        using strict from another module
        I haven't used either, and I fear that you'll get bitten by ETOOMUCHMAGIC if you use them instead of simple templates --In addition to the Pod, I describe there's really very little magic involved in ToolSet
        Devel::Declare vs LISP like macros...
        Heh. Checking the reviews of one of the example modules, "Make sure that you have the latest Devel::Declare or you can have some weird issues that won't seem to make any sense". Exactly the type of error that result from source filters... ...The bane and hallmark of ETOOMUCHMAGIC.
        Use of wantarray Considered Harmful
        As for the several recommendations of Contextual::Return, I have to disagree. That module appears to have been implemented in a way that suffers significantly from ETOOMUCHMAGIC and I happily avoid it and encourage others to as well.
        Some thoughts around the "is Perl code maintainable" discussion
        ???
        Re^3: Your favorite objects NOT of the hashref phylum (inherit)
        I strongly dislike class-making frameworks that everyone and their dog wants to bolt onto the side of Perl. So I'm not going to be writing any plug-ins for one. I've never seen any significant value in any of them and most of them look quite prone to break things due to ETOOMUCHMAGIC (and I've seen several actually break things), so I'm quite happy to avoid all of them completely.
        Re: POD from code?
        create my data (not code) from POD ; Usually I find that approach to be a bit too much magic,
        removing someone elses AUTOLOAD
        PS I think I recall in Damian's PBP Dog book, he states AUTOLOADs are bad, and I agree! Too much magick.
        Re: Can't seem to use an AoH with Template::Toolkit
        In short, the problem is too much magic. When you call $cgi->Vars, you don't get a normal hashref. Instead
        Re: email pdf file - file damaged
        I have my reservations about IO::All, especially once you move from a hardcoded filename to anything variable because it reopens the security hole that was fixed by introducing the three argument form of open.
        but I would entirely stay away from IO::All for it heaps too much magic onto magic and relies on the undocumented assumptions made by Ingy.
        Re: Overloading print()
        operator Overloading can be very convenient, but too much magic can hurt maintainability.
        Re: WSDL generation for a SOAP::Lite server
        WSDL::Generator currently tries to use too much magic, and the resulting WSDL is not exactly easy to document.
        Re^6: RFC: Is there more to alias?
        You still misundestand how Data::Alias works, and you seem to see too much magic where there is none.
        Re^18: use fields; # damnit
        It just shouldn't be used on the application logic level too much magic is a nightmare.
        Re: Wanted: Spiffy evangelist
        Maybe the fact that nobody has voted on Spiffy yet could be a warning sign?
        To me, Spiffy is yet another way of being too clever for your own good. It is Ingys object framework, and it is mainly used for Spoon, which in turn is a nice thing for very small, very contained scripts and nothing else. I am wary of using modules that contain way too much magic, and if I were to build a bigger framework, I wouldn't rely on anything that requires a larger span of attention from Ingys part.
        WOW, ingy, author of Spiffy, is using Spiffy in modules he is writing/maintaining? You don't say /sarcasm
        Re: Your favourite gory detail...
        Using eof() with empty parentheses is very different...That's just too much magic for one parenthesis!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1052605]
Approved by toolic
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-12-21 17:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (106 votes), past polls