views:

168

answers:

4

I have several scripts that I supply to users as tools for their engineering projects. These scripts contain a lot of duplicated code. I want to extract this code and maintain it in a set of modules. However, in order for this to work, the users would have to install these modules. I don't want to have to tell my users to "make install", etc., as I'm sure none of them would have the patience for that.

I understand that one option is to package everything together with PAR, but ideally the user would be able to open up && edit these scripts if they need to, just like they can now. They also need to be able to move them to whatever directory they want, and I don't want them to have to move a bunch of library files as well.

Is it possible to make a double-click file that installs some bundled Perl modules?

+1  A: 

If the users are using systems with a packaging system (dpkg, cygwin, etc.), consider using that.

ysth
I had never thought of this, though virtually none of my users are using anything like that, unless XP has some packaging system...
Joe
+1  A: 

If you don't mind spending some green, one of the better bet is Perl Dev Kit from Activestate.

From their own description of the product,

  • Develop and deploy your Perl programs to anyone on any platform with PerlApp's new cross-platform wrapping.
  • Deliver code as executables or as Windows Services, ActiveX components, .NET assemblies or in the System Tray.
  • Easily create MSI files using Perl code.
rahulbatra
I've heard that Perl Dev Kit is good, but there has to be a cheap-as-free way. Especially since I'm doing this work au gratis.
Joe
+3  A: 

yeah package with either PAR or Shipwright (not sure about binaries). Also use scandeps.pl along the way.

xxxxxxx
Well, PAR creates a single file, but it's not a binary.
brian d foy
hmm , better correct that , thanks brian. but it sure makes them +x so I assumed they were binaries(although I read it just zips them up and stuff...), anyway...
xxxxxxx
+5  A: 

I distribute my script as modules, and then use the normal CPAN toolchain to install them. See my articles Scripts as Modules and Automating Script Distributions with scriptdist. Once you have them in a conventional module distribution, you can install them from their current directory with cpan:

 % cpan .   # install from distribution in the current directory

Depending on how complex your situation is, you might want to create a DPAN, which is a private version of CPAN that your CPAN tools can draw from. You put all of your private modules there, point your CPAN tools at it, and everything happens as it does with a real CPAN mirror. You never have to share your work though.

brian d foy
I've thought about this for awhile, and I really like this answer. Those articles are Good Readin' too, by the way.I'm not sure if I could even go this far (I work with some not-so-computer-savvy engineers), but this is probably the best answer to the question asked, especially since it's different from just packaging with PAR.
Joe