Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

scripts on CPAN

by dk (Chaplain)
on Mar 23, 2007 at 08:21 UTC ( [id://606184]=perlquestion: print w/replies, xml ) Need Help??

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

Hi all, I'm not sure how relevant my question is, but I can't find the answer elsewhere, so I'll ask you all. Suppose I wrote and released a perl module that I intend to use in other projects, to be installed as automatic dependencies, etc and all is fine - the answer #1 here is CPAN. Now comes slight adjustment: I wrote and uploaded to CPAN a perl script, which I also intend to use in other projects and to be installed as an automatic dependency. The problem is that this script cannot be then found neither using web nor 'perl -CPAN' searches, even though the script package has all attributes that could theoretically be required for this, such as, POD section, META.yml etc.

So, here's the question: is this behavior intentional? Or it is so just noone bumped into this before? OTOH if there's a way to tell CPAN that a package comes without modules, but should be available in searches, would someone please tell me how? Thank you.

Replies are listed 'Best First'.
Re: scripts on CPAN
by xdg (Monsignor) on Mar 23, 2007 at 10:50 UTC

    The CPAN dependency management system is really designed about modules, not scripts, though I'm surprised that the search system has that same problem. However, one easy option is just to add a module that describes your script. E.g.

    package My::Script; $VERSION = 0.123; use strict; # keeps CPANTS happy 1; __END__ =pod describe your script here =cut

    Another option is to turn your script into a module.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      As xdg said, the issue that CPAN distributions are all about modules is pretty recurring. For instance, that's why the easiest way to install the ack distribution (which comes with the ack script) is to say

      cpan> install App::Ack
      where App::Ack is a companion module that lives in the same distribution. Otherwise, you may take a look at the author directory with
      cpan> ls PETDANCE or cpan> ls PETDANCE/*ack*
      and hope to see something in the sea of released distributions.
      Another option is to turn your script into a module

      That amounts to a good piece of advice as it can make your code more reusable both as the script (for external users) and as a module (for fellow Perl programmers).

Re: scripts on CPAN
by philcrow (Priest) on Mar 23, 2007 at 13:16 UTC
    The fundamental reason the CPAN script system doesn't work as well as the module system is that we want you code, but not just your script. We want whatever your script does to be available through a module API so we can plug it in to our work instead of having to shell out to it. Hence, when you write a script others might like, you should factor out the operative bits into a module. Then have your script use that module. Put the script in the bin directory of the module's distribution and add it to the list of executables in your Build.PL or Makefile.PL. Then we can get to the juicy bits of your code in our code, or use your script as is. Give the people what they want: choice.

    Phil

      I understand all these (valid) reasons, and release modules when the corresponding concepts can be used as modules. But there are cases that don't fit in the box, and neither should, and I'm talking exactly about these cases. Not to be empty-worded, here's a concrete example (excuse me for a shameless plug of my own script):

      http://search.cpan.org/~karasik/sqlpp-0.05/bin/sqlpp

      This is a simple cpp-like preprocessor with injections of perl syntax. It can be done in a thousand different ways, and if I indeed generalize it as a module, I'll need to justify the existence of it, especially when there's Text::Template and what not. The point is that there's not much to generalize, really. Who needs yet another CPP.pm with fixed syntax?

      Another example, to show when indeed creating a module is possible, but not necessarily needed:

      http://search.cpan.org/~karasik/Subtitles-0.09/subs

      this is the script that comes with a module, and even though the concept is generalizable, I seriously doubt that anyone would use this module to write their own subtitle handling program. Suppose I'm wrong, for the sake of argument, but why then we have this?

      http://search.cpan.org/~miyagawa/Video-Subtitle-SRT-0.01/lib/Video/Subtitle/SRT.pm

      when the subtitle module I wrote is already there? I'm not jealous in any way, let the thousand flowers bloom etc. but I don't want to create a different module when all I want is a different program. I think that this is exactly the case when entities should not be multiplied beyond necessity. I don't know who is "we" who "want my code", thanks for that :) but I neither think that you should generalize what people want from CPAN.

Re: scripts on CPAN
by dk (Chaplain) on Mar 23, 2007 at 17:14 UTC
    Thank you all who answered, I'm thinking how about for all us who are interested in scripts on cpan, we'd include a top-level dummy empty file, f.ex. bin::MyScript.pm ? I'll open a topic in Meditations to see if people come with better ideas.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://606184]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2024-04-19 14:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found