Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Packaging files with a module

by KSURi (Monk)
on Aug 31, 2011 at 15:41 UTC ( #923451=perlquestion: print w/replies, xml ) Need Help??
KSURi has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I have a module Foo that uses some pre-calculated data from files. There is another module Foo::Updater that downloads newer versions of the files from the internet.

I'm planning to upload these modules to CPAN later. What are the best practices for packaging files in modules?

Replies are listed 'Best First'.
Re: Packaging files with a module
by Anonymous Monk on Aug 31, 2011 at 16:09 UTC
    To store some data at configure time, use File::ShareDir::Install, Module::Build >= 0.35_02 or Module::Install::Share. File::ShareDir is used to access these data.

    Forget about auto-updating, it's a bad idea. Sysadmins will want your head for trying to subvert their control over the systems they take care off. Instead simply put out a new release and leave the updating to the people in charge in the OS distro toolchain and the end-user sysadmins.

      I disagree. I think auto updating of data is sometimes important, and Sysadmins often have more important things to worry about, especially if they are remote from the users of the perl module or if updates are frequent.

      I have been a perl user in large bureaucratic corporations before, and trying to get a perl module installed system wide (so that any of my users could run a script that used it without further configuration) required months of lobbying. If I had asked for a cron job for auto updates as well then that would have been impossible. Needless to say we where stuck on perl 5.6 for years.

      My view is that if updates are infrequent, (eg yearly), then just include the file in the distribution and release a new version when it needs updating. If updates are predicable in advance then you can make the module complain if it is to old.

      If the updates are more frequent (eg weekly) than that then provide an update mechanism that can be used both by the sysadmin if they care, or by an unprivileged end user within the script that uses the module. I would have something like:

      use Foo; use Foo::Updater; Foo::Updater->new->update() # Rest of script here

      That call to update would compare the timestamp of a local cache with the latest version on your server, and pull the update if required. If the user is non privileged then the update gets put in their home directory. If the user is root then it goes to a central system wide location that all users can read. That way if the sysadmin cares, (Or if they notice the disc space and bandwidth consumption of hundreds of identical copies of the update data) they can setup a cron job to pull the updates, but if they don't care then users get the data anyway without their intervention.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://923451]
Approved by davido
Front-paged by chrestomanci
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2017-04-29 01:50 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (531 votes). Check out past polls.