Install on demand ?

[Bod]

I am using Spreadsheet::Read to provide a universal way to read spreadsheets that users upload. I'm using this module because I have no idea what flavour of spreadsheet users might want to upload.

This module relies on others to do the work of reading the data. Is there a way to install the modules it uses "on demand"? So only when we first see a Lotus 1-2-3 spreadsheet, for example, do we install the module to read it.

The purpose of this is to convert the spreadsheet to CSV, so I have it in a standard format for the next part of the processing, which is mapping the data fields ready to import into a CRM - perhaps I am overthinking the universal spreadsheet part...

[Corion]

Personally, I would install everything relevant upfront just to be sure that the installation is in a known good state.

An alternative could be to inform the user about the recommended modules using the recommends keyword in Module::CPANfile (if you use a cpanfile to install the prerequisites).

[marto]

Lotus 1-2-3 stopped being a supported thing 22 years ago, where in Spreadsheet::Read do you see support for the wk* formats? Obviously you need to install the modules before they can be used, this shouldn't be triggered by an on demand action.

[Bod]

Lotus 1-2-3 stopped being a supported thing 22 years ago

It was the only spreadsheet I could think of off the top of my head that isn't Excel and isn't Google Sheets!

[hippo]

The purpose of this is to convert the spreadsheet to CSV, so I have it in a standard format for the next part of the processing, which is mapping the data fields ready to import into a CRM - perhaps I am overthinking the universal spreadsheet part...

This. I would allow the users to upload a CSV rather than some other format then the problem just goes away.

[Bod]

I would allow the users to upload a CSV rather than some other format then the problem just goes away

We do allow users to upload a CSV file...
However, our target market is charities - they are often run by people with restricted IT skills and saving an Excel file as CSV will be beyond some of them.

But it probably makes sense to get this working with an uploaded CSV file then get the spreadsheet conversion working later.

[afoken]

people with restricted IT skills and saving an Excel file as CSV will be beyond some of them

From my experience, those people with low IT skills don't even know that Excel can save in different formats, and so each and every file that opens in Excel is called an Excel file - CSV, XLS, XLSX, XLSM, and so on. Completely logical from their perspective, and a big mess when you are in IT or application support. But that is also an advantage. All they know is Excel and MS Office, and they don't have the slightest idea that things like OpenOffice / LibreOffice, KOffice or Gnumeric exist. Maybe some users with DOS experience still remember Lotus or Quattro Pro. So, it is very likely that almost all spreadsheet data comes in either as CSV or in one of the Excel formats.

Alexander

[talexb]

Is there a way to install the modules it uses "on demand"?

Here's what I've done in one script:

 202     my @variables =
           qw/User Password Url Prefix CommPlan ApiVersion/;
 203     foreach my $site ( grep { $_->{'enabled'} == 1 }
           @{$json_config} ) {
 204 
 205       use lib '/some/path';
 206       eval "use FOO::$site->{'module'}";
 207 
 208       my %variables =
 209         map { $_ => eval '$' .
               join( '::', 'FOO', $site->{'module'}, $_ ) }
 210         @variables;

This pulls in variables for each individual website, where the website credentials are stored in modules -- which are not stored in version control, obviously. I could also have put them in json files, but I liked the idea of using a module so that I could add dated comments to remember related information.

[swl]

You could implement something based on lazy.

However, if this is running on a server then are there reasons not to install all the optional dependencies for Spreadsheet::Read?