in reply to Building a CPAN module with User Inputs

In a word: "Don't". Modules get installed in all manner of ways which preclude user interaction. If you require information such as that for customization, pop up some ui the first time the module is used to ask for it, then save the information away in some place relative to the place the module was installed (if you can) or in a user relative location (if you can find one). Note that where you can store such stuff will depend on the host OS and on various other things outside the control of your module.

Perl reduces RSI - it saves typing
  • Comment on Re: Building a CPAN module with User Inputs

Replies are listed 'Best First'.
Re^2: Building a CPAN module with User Inputs
by bichonfrise74 (Vicar) on Oct 28, 2008 at 05:55 UTC
    I found this notes from the book of Perl Hacks by Damian Conway, specifically - Hack 17. Collect Configuration Information. 

    Some code you write needs configuration information when you build and
+ install it. For example, consider a program that can use any of seve
+ral optional and conflicting plug-ins. The user must decide what to u
+se when she builds the module, especially if some of the dependencies
+ themselves have dependencies.

When you run your tests and the code in general, having this informati
+on available in one spot is very valuableyou can avoid expensive and 
+tricky checks if you hide everything behind a single, consistent inte
+rface.

How do you collect and store this information? Ask the user, and then 
+write it into a simple configuration module!

    [download]


    Then he presents his code which he describes as extending the Module::Build. I tried to run his code but was getting errors -- "Can't locate SUPER.pm in @INC..." . I wonder if there is a simpler version of implementing what Damian Conway mentioned in his book.
[reply]
[d/l]

      The situation Damian describes as an example is somewhat different than your use appears to be. In the case Damian describes the information is required to tailor an installation including dependencies at install time. In your use case that does not seem to be the requirement. That is to say, the installed materials (except possibly some configuration constants) are not affected by the information that would be provided by the user at install time.

      It is better to avoid interrupting the install processing with required UI because that breaks automatic install processes. Where that requirement is known up front it's not so much of an issue, but if some module in the future requires your module to be installed the UI requirement could become rather troublesome. There's a lot of hand waving going on there of course and it could well be that the ifs and buts are not relevant or are a cost that you and users of your module are happy to accept.

      The ultimate answer is that your module is (conventionally) installed using makefile.pl to build a makefile that then is used to install and test your module. Guess what, the makefile.pl is a Perl script! You can edit it to do whatever you need. In the simplest case you could prompt for the required information then write that to a configuration file that is installed with the module.

      Perl reduces RSI - it saves typing
[reply]
        Thanks for all the inputs, monks.

[reply]
Re^2: Building a CPAN module with User Inputs
by bichonfrise74 (Vicar) on Oct 28, 2008 at 05:01 UTC
    Hmm... Sounds like my idea is not really that great after all.

    Thanks for your input.
[reply]
Re^2: Building a CPAN module with User Inputs
by Anonymous Monk on Oct 28, 2008 at 04:33 UTC
    username/passwords don't usually belong in modules
[reply]

In Section Seekers of Perl Wisdom