Re^2: Cat'ing perl modules into single file script

I don't see why scenario 1's calling constraint precludes installing a number of modules and a script that uses them into a single directory. I do know it was a PITA getting a number of modules merged together into a single script file and that it is easier to maintain the code in a number of module files than as one monolithic file.

Perhaps you need to paint a bigger picture so it's easier to see where the issues really are?

Perl reduces RSI - it saves typing

Comment on Re^2: Cat'ing perl modules into single file script

Replies are listed 'Best First'.
Re^3: Cat'ing perl modules into single file script by Smitty (Beadle) on Nov 24, 2008 at 04:33 UTC
Agreed, a PITA it has been to manage. Bigger picture... Originally, I developed A.pl, and then later B.pl. Since there was much common code, I split the common code into M/.pm. The management of code in this fashion, while convenient for me to develop, doesn't fit/install naturally into an existing software package. I don't want to pollute the file namespace of the existing software package by placing .pm into the same directory as A.pl or B.pl. And A.pl and B.pl may both be installed at the same time, but use (eg. be built with) different versions of .pm at the same time, so I can't just create a single M module subdirectory for M/.pm. The existing software package already reserves the file namespace of the installation directory (so I don't want to usurp any name M inwhich to install M/*.pm). If there is a way to avoid the contrived single-file packaging as I do now, that would be fine. Or if there is some (better) tool that does what my build packaging script already does, that would be fine too.	[reply]
Re^4: Cat'ing perl modules into single file script by GrandFather (Saint) on Nov 24, 2008 at 09:39 UTC
I can think of a number of options, probably none of which you will like a lot, but one of which may be acceptable: 1/ Always use the latest version of the modules regardless of the combination of A and B that you have installed. It is natural for modules to evolve, but they should evolve in a controlled fashion so that later versions of a module do not break earlier scripts. Unit tests can check that that is the case. Just from a maintenance point of view the interface to a module should not change a lot over time because ensuring the correctness of use becomes problematic if it does change. 2/ Name the directory containing the module differently for the two scripts so that the scripts see different versions of the module. 3/ Always use the latest compatible version of the module and include a version number in the module name. Change the module name version number when there is a significant change the the interface. This is somewhat like option 1 with an escape clause for when you need to do a large overhaul of the module interface. Perl reduces RSI - it saves typing	[reply]