Avoiding extra dependencies in co-developed module and application

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

Hello dear esteemed monks,

Say I have an example script in my CPAN module's distribution. Over the course of module development it grew and gained enough features, robustness, and documentation to be considered a tool on its own. However, it also uses other modules that are not used by my module, and I don't want to introduce extra dependencies. Say the module is about data processing and tool uses drawing tools to visualize the data.

Now here are some options I see:

Just add extra dependencies - but I don't want to clutter my users' systems.
Split the tool into separate project (App::mytoolname) - would make development somewhat tricky.
Make my tool look up required dependencies and ask politely to install them if missing.

Looks like option 2 is the way to go, but how can I do it? Keep 2 CPAN packages in the same repository? Maybe I can tweak Makefile to copy a script to a separate location an process it there?

Or maybe there's a fourth option I miss completely? Where should I look for example?

Comment on Avoiding extra dependencies in co-developed module and application

Replies are listed 'Best First'.
Re: Avoiding extra dependencies in co-developed module and application by VinsWorldcom (Prior) on Dec 10, 2015 at 14:55 UTC
I'm by no means an expert, but have used 2 and 3 for various reasons. Shameless self-promotion as example relevant to answer to follow: I developed Cisco::SNMP and the distribution has several simple example scripts. For a much more comprehensive tool, I have https://github.com/vinsworldcom/crapps, which uses Cisco::SNMP - so in this case, I'm using option 2 - split the module and the "tool on its own". With the CRAPPS tool on GitHub, it not only does the SNMP stuff (with Cisco::SNMP) but also does Telnet and optionally SSH and other stuff too. So it requires Net::Telnet::Cisco but will run without the optional Net::SSH2::Cisco - you just don't get the option to use SSH. There are other modules which I optionally use so if the user doesn't have them installed, the script still runs and if they request an option that requires a module that is not installed, it produces a nice error telling them they need a module to use that feature. So that is like your option 3. So a question could be, does your tool run without the graphing modules such that you can make them optional? If they are conditionally used, maybe you don't have to have extra dependencies, but if the user sees your PerlDoc and tries to use the graph, they get a nice error message saying they need to install an additional module, but for users not graphing, it will work without additional dependencies. `VinsWorldcom@C:\Users\VinsWorldcom> crapps --ver Modules, Perl, OS, Program info: C:\usr\bin\crapps.pl Version 3.02 - 09 JUL 2015 strict 1.07 warnings 1.18 Getopt::Long 2.41 Pod::Usage 1.63 Sys::Hostname 1.17 Socket 2.013 Cisco::SNMP 1.01 Net::Ping 2.41 Net::Telnet::Cisco 1.10 Net::SSH2::Cisco [NOT INSTALLED] Crypt::PasswdMD5 [NOT INSTALLED] Term::ReadKey [NOT INSTALLED] Perl version 5.018001 Perl executable C:\strawberry\perl\bin\perl.exe OS MSWin32` [download]	[reply] [d/l]
Re^2: Avoiding extra dependencies in co-developed module and application by Dallaylaen (Chaplain) on Dec 11, 2015 at 14:42 UTC
Makes sense. However, I would like to keep both the library and the tool under the same repository for as long as possible. My development process (or lack thereof) often includes simultaneous edits to both. I don't want to add jumping between directories to the mix...	[reply]
Re: Avoiding extra dependencies in co-developed module and application by jeffa (Bishop) on Dec 10, 2015 at 22:54 UTC
"Make my tool look up required dependencies and ask politely to install them if missing." This is exactly how i solved a similar problem i had with Spreadsheet::HTML. If the client does not use certain features that require dependencies, why require those dependencies. I do this via `eval` and as such, i lost the ability to import methods/functions, but always found a work around. You can see more here, but the edited version is: `eval "use Spreadsheet::Read"; our $NO_READER = $@; # and then later return [[ "cannot load $file" ],[ 'please install Spreadsheet::Read' +]] if $NO_READER;` [download] Which is presented back to the client. Hope this helps. jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply] [d/l]