11

I develop and maintain a bioinformatics application suite of 50+ scripts and its deployment process is a mess:

  • Entire suite is in one big git repository. It has lots of CPAN dependencies, and dozens of internal modules as well.
  • Development platform is Linux.
  • Deployment platforms are Windows (20+ users), Mac (10+), Linux (2-3). Most are not 'power users'.
  • For windows, I have one installer (made with NSIS) for strawberry perl + required modules (ie, I installed strawberry on a windows box, installed all modules and zipped c:\strawberry), and another installer for the suite-- I did this b/c the suite is updated a lot more than the list of required modules.
  • For Mac, I bundle perl 5.14, all required cpan modules, and the application suite into a double-clickable installer. I don't use the system perl b/c it tends to be out of date. I bundle everything together unlike on windows b/c I suck at mac.
  • For Linux, I handle their installations manually since there are only a few of them, and they use different distros.

This is obviously a mess that grew organically over several generation of developers. Ideally I would like to create cpan-installable distributions out of the internal libraries and various groups of related scripts, and use module dependencies to let cpan install them for me.

But I'm not sure what the best approach for this is, b/c I'd still need distribute perl itself, would have to write some sort of non-command-line interface to CPAN, control the exact versions of 3rd party CPAN modules, point it by default to my "DarkPan" where I would store our modules, how I would push updates, etc. etc.

I don't think I can use PerlApp or Par since afaik those are for bundling single scripts, not an entire suite of them.

Any advice highly appreciated.

user1481
  • 849
  • 1
  • 5
  • 15

2 Answers2

2

Besides the 3 platforms mentioned (more, if you count the Linux variants), you really have a couple different problems:

  1. Deployment of a standard known-good Perl executable and libraries (CPAN modules).
  2. Deployment of your Perl scripts and modules.

Once upon a time, I supported a large Solaris Perl installation. I tried for a while to stand up a Linux Perl installation "side-by-side", re-using the same CPAN modules. Didn't work. The big problem for me is that a fair number of Perl modules require compilation, which means they target a specific platform. I ended up just with 2 installs, and always remembered to install a new CPAN module in both areas.

We're now 100% Windows, so I don't have the same issue. However, we do run Perl off a shared network drive. All the users map this drive, and run a Registry script that associates .PL files with the network install of Perl. (See my answer to this other Perl question.)

So, besides the mapped drive and the Registry script, users don't need to install anything. Even the CPAN modules are picked up from the network. This solves item #1 (for Windows only users).

Same thing holds true for item #2: the scripts are stored on a network drive (same one) and the users run another Registry script to include the scripts folder in their search PATH. We edit our scripts in one area, and have a "Check-In 'n Release" ("CINR") that we use to, well, check-in and release scripts to the area the users point to. The users can double-click the scripts in Explorer, run them in DOS, or even better yet get them included in the contextual-menu in Explorer, etc. (Actually, we use a .NET application to map the drive and make all these settings for the user, but it can be done much simpler.)

So, how does this help with the other platforms, Linux and Mac? As I ran into with my Solaris/Linux experiment, I think you're stuck with different Perl installation for all 3 platforms, although you should be able to reach the same network drive for your Perl scripts and modules.

The Perl installation might even be OK on a network drive for the Linux users. It's probably easier for them than the Windows users. Mac users are tough. I administer a home Mac network, and I think network drives are very difficult to do in Mac OS X compared to other OSes. It should be as easy as in Linux since so much is the same, but there are very strange problems (for me) mapping NFS and SMB drives. AFP drives are a little easier for the user to map manually, but not so easy to map programmatically.

My Mac recommendation is to try using Platypus. It's definitely great at bundling scripts into a double-clickable application, although your interface options are limited to output only (no user input allowed during execution that I can tell). Not sure if you could put an entire Perl installation into the Platypus app or not, but if you could the paths figured out, you might be able to.

Good luck!

Community
  • 1
  • 1
jimtut
  • 2,366
  • 2
  • 16
  • 37
  • Sorry, I should've been clearer... many of the 'users' of my scripts are in different organization and I have no direct control over computers (though about half are also in the same building as me). Platypus looks promising, though. EDIT: on second thought, even for just half the users, if I didn't have to worry about machine-specific installation issues, it might well be worth it... – user1481 Mar 06 '12 at 03:22
  • Presumably your users are interested in running your scripts. In other words, they WANT to, they're not being forced to do something they'd rather skip. For my 200 worldwide users, they WANT to run them, so they're willing to run the setup scripts to map the drive needed, associate the .PL files, etc. If this isn't something that these people need to or want to run, getting them to go through this extra setup might be even tougher! But, some setup scripts and a network install of Perl, CPAN modules, and your custom scripts and modules is a nice start. – jimtut Mar 07 '12 at 03:04
0

You may wish to check out CAVA packager. It can deal with multiple scripts in a single package.

Johan Vromans
  • 1