pboin has asked for the wisdom of the Perl Monks concerning the following question:

So, I've got a pair of scripts that do some simple manipulation1.

I'm thinking about getting them cleaned up to share with the world-at-large. Now, I know that CPAN is (mostly) module-oriented. I also know that many people will use the script version, as I do. Right now, the scripts(s) are *not* modules, but I'd be happy to convert them if that's the right-thing-to-do.

So, how would you recommend I offer this code so that is most useful to others:

1 They are replicas of IBMs IEBPTPCH and IEBUPDTE that let me work with PDS members on my linux box and then put 'em back up on the mainframe.

Replies are listed 'Best First'.
Re: Distribution of Program and/or Module
by dragonchild (Archbishop) on Mar 10, 2005 at 14:47 UTC
    Module on CPAN. There's several benefits:
    1. I might want to do things your script doesn't do, but I want to reuse your code. Maybe, I want to implement IEBPTPCH on A, but fail-over to B if A can't be gotten. Easy to do if your code is a module, but not so easy if it's a script. Or, I might want to do DBI commands while I use your module.
    2. I might want to implement other IBM Mainframe commands.
    3. I might want to use your API to talk to a CRAY instead of an IBM mainframe.
    4. Having a module allows it to be easily integrated into a persistent environment, such as mod_perl.
    Scripts don't have the flexibility modules do.

    Now, this isn't to say you shouldn't distribute your script as part of your CPAN distribution. There is a place for scripts and it would be an excellent example of how you have used this module.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

      Let me expand on this just a wee bit.

      One of the developers reporting to me wrote a very useful script that we needed. However, he wrote it as a script rather than as a module. What that meant is that I could not embed it into the overall perl project that we are using - well, not easily. I rejected his implementation (would not sign off on it) based solely on this aspect. He is converting it into a module right now.

      Yes, it's that important.

      He will also create a sample script that all it does is convert the command line parameters into arguments for calling the function in the module. So the external behaviour will be unchanged, but the internal behaviour will allow us a lot more flexibility. We're going to be using the code in ways I'm sure he hasn't imagined (because if he had imagined, the code would have been a module in the first place). These other things include things such as reading the parameters from an XML-like datastore, or reading lists of files from the filesystem. The latter is one he thought of, the former is not.

      Thus, I'd suggest creating a tarball that included the module with all the functionality, and a wrapper script that allows you access to that functionality from the commandline. It would also serve as an example for those who wanted to write their own scripts to do other things, or to get input from various locations.

[reply]
Re: Distribution of Program and/or Module
by Anonymous Monk on Mar 10, 2005 at 14:48 UTC
    CPAN needs more ready to use programs. Modules are useful, but they are like Home Depot, that sells you tools and lumber, but leaves it to you to make a table. But most people just want a table.

    Now, what you could do it put the reusable functionality in a module, and have the script use the module to its work. Then you upload both to CPAN. Could be in the same tarball.

[reply]

      I higly disagree on this, for I believe there should be no ready-to-use scripts on CPAN, but only modules. (CPAN ne hotscripts.com).

      I see CPAN more like an IKEA than a Home Depot. It provides you with all the stuff, but you'll have to put it together yourself.

      Also I think that good POD (with examples) is worth more than ready-to-go scripts that people don't care to check before running.

      --
      b10m

      All code is usually tested, but rarely trusted.
[reply]
        So you'd would use Pod::Perldoc; all the time instead of running perldoc? Didn't think so.

        The P in CPAN stands for Perl, not module.

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
        You know, I was first thinking of IKEA myself as well. But if I buy something from IKEA, say a table, it comes with clear instruction how to assemble that specific table. And I can't use the parts to make something else.

        Now, if I get something from CPAN, it's not "ready to assemble to do a specific task". Instead, it may provide some of the functionality you're seeking, but it can also be used to create something else. Ergo, Home Depot, and not IKEA.

        And I do think CPAN is for more than modules. Luckely, the maintainers of CPAN think so as well, and named it CPAN, not CPMAN. If it would be just for modules, you wouldn't be able to get the perl sources from CPAN.

[reply]

Back to Seekers of Perl Wisdom