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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]