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

Esteemed Monks,

I'm writing a Perl module that reads values from 3 TXT files (in total those files have about 5K lines). These files are not maintained by me, they are on public domain AND sometimes are updated but preserving the structure.

My question is: how should I include those 3 files in my module?

  1. Directly (copy&paste) into the Module as hashtables?
  2. As external files, included in the package? (in this case, please, enlighten me on doing this)
  3. Let the programmer download the files and copy them into the programm's folder.

In cases 1 and 2 each time those files are updated I'll have to update the Module. In the later case the programmer is responsible for updating the sources (those 3 files).

What would be your choice?

Miguel

Replies are listed 'Best First'.
Re: Module and external files
by PodMaster (Abbot) on Oct 18, 2004 at 14:31 UTC
    Here's one approach that I'd likely take
    $ perl Makefile.PL Downloading the files ... success Parsing .... success Generating module (inlining those big hashes) .... success Writing makefile ... $ make ... $ make test ...
    Get the picture? If its not feasible to inline the text files, then placing them in the appropriate "auto" directory would work (like AutoLoader does).

    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.

      I think that would be OK if he owned management of those files. But alas he is saying he does not -- why would you have those files auto download if you can't guarantee updates are compatible. What happens if the maintainer of those documents updates the structure? What happens when his module gets blacklisted because of a tracking portion (hitting a webserver durring make install).


      -Waswas
        He said they are on public domain AND sometimes are updated but preserving the structure. This means they won't change. When they do, he updates the module. Since they're public domain there is nothing prohibiting him from distributing a copy, but the Makefile.PL should always (offter to) check to see if the included ones are the latest.
        What happens when his module gets blacklisted because of a tracking portion (hitting a webserver durring make install).
        As long as he prompts the user there are no issues.

        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.

Re: Module and external files
by Taulmarill (Deacon) on Oct 18, 2004 at 14:32 UTC
    there should at least be some dummy files so you can perform some tests when installing the module. i think it would be the best way to include some files of whatever but make it obvious that there are newer/larger/better versions out there on the net.
Re: Module and external files
by duff (Parson) on Oct 18, 2004 at 15:20 UTC

    I would pick a combination of #2 and #3. Include the latest files with the distribution, but remind the user that newer files may be available and where to get them (and warnings about compatibility). They should be separate from your module so that it's easy for the user to update them. (Unless your module is extremely tightly coupled to the contents of these files, then I'd just include them in the module and be done with it)

      "Unless your module is extremely tightly coupled to the contents of these files"

      It is indeed. These files are the sources of information. Without them the module doesn't work at all. Without these files the module is useless.

        You could use PAR to package everything into a single file and then distribute that. You'd then use PAR::par_handle( $0 ) to get access to the contents of your extra files.