How to store data for a perl module

Scott Penrose scottp at
Sat Feb 23 19:24:49 CST 2002

Hash: SHA1

On Sunday, February 24, 2002, at 11:19 , Jeremy Howard wrote:

> Scott Penrose wrote:
>> However I have a standard data format that is used by multiple systems
>> (including a pending Java version etc) so putting it in DATA is not a
>> really good idea.
> Why does the data format stop you from storing it in DATA? DATA is a
> location, not a format--you can store even binary formats there 
> particularly
> if you base64 encode it first.

Sorry I have not explained myself then.
Of course there is nothing stopping me storing in the DATA section.

My point is the opposite. I am REQUIRED to store the data in a separate 
every day data format, not in the module directly.
If I do there are a set of major disadvantages

1) The file can't be easily shared with other programs - eg: a Python 
2) The data file can't be edited or maintained independently.
3) The data file (which is currently a separate file) would have to be 
inserted into the perl module, and the perl module updated (version and 
uploaded to cpan etc) each time the data file changes - which is not a 
good idea.

> Have you looked at Inline::File? That module takes you beyond just 
> plain old
> DATA sections to creating any named section you like, and treating it 
> just
> like a real file.
> If you need to find a real path to use because you really can't use 
> use File::Spec to help you create non OS-specific path names.

Yes I think this is the approach I will have to take. It just isn't so 

This problem is not just with data files either. Some programs require 
other 'helpers'. A simple example is a perl module which uses a set of 
existing images to generate another image. These images must already 
exist somewhere. The standard in unix would be to put them in the 
application directory, usually something like /usr/lib/XYZ/images/* or 
/usr/share/XYZ/images/* (which would be the better debian and standard 
directory structure style). However this is not portable to Windows, 
MacOS or probably others.

Storing resources (fonts, images, data files, templates, schemas, style 
sheets etc) should not be forced to be installed in the data section of 
perl modules. I have researched a few other tools which heavily use 
resource files (eg: Template toolkit) and it seems the only solution is 
to ask for the location (with some suggestions with File::Spec) during 
'make Makefile.PL'.

Perhaps we should create a standard for this, rather than all different 
(eg: Template toolkit generally stores files in /usr/local/tt2/). If we 
had a standard library to use we could not only automate the questions 
during Makefile.PL but also have a standard way to lookup what the 
locations stored are, a bit like you can look at what modules from cpan 
are installed.

- ---
Scott Penrose
Open source and Linux Developer
scottp at
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see


More information about the Melbourne-pm mailing list