How do you distribute your Perl application to your customers?

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

Replies are listed 'Best First'.
Re: How do you distribute your Perl application to your customers? by Corion (Patriarch) on Jan 11, 2010 at 11:21 UTC
Why not use PAR::Packer? Other people seem to use the Cava Packager, others again use the ActiveState Perl Developer Kit.	[reply]
Re^2: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 11, 2010 at 14:18 UTC
Thank you for your answer! I wanted to know if there are obvious better solutions than using PAR::Packer. (Dont't get me wrong, I try very hard to use PAR::Packer but I struggle and don't know if I will succeed in time.) Cava Packager looks promising. I will give it a shot. ActiveState PDK is on my wishlist for the next project. In a company that scores 0 on the Joel Test, it is sometimes difficult to get the best tools for the job on time - but I try to change that :-).	[reply]
Re: How do you distribute your Perl application to your customers? by zentara (Archbishop) on Jan 11, 2010 at 13:04 UTC
See Camelbox: A build of Gtk2-Perl for Windows.... works great for me, in limited testing. It installed Perl5.10 in my last test, plus you get a working Gtk2 GUI toolkit, for making fancy windowed applications. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku	[reply]
Re^2: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 11, 2010 at 14:27 UTC
In fact, I also use Camelbox (which is just great) but plain old Tk. I don't know how Gtk2 works. Do you pack the Perl distribution in an archive or executable? What do you do with non-core modules? Thank you!	[reply]
Re^3: How do you distribute your Perl application to your customers? by zentara (Archbishop) on Jan 11, 2010 at 16:07 UTC
I don't distribute programs.... I write for my own machines, and for educational examples. But, if I was to do it, I would put your code into it's own module, then tar gzip it up, and you could mail it to them on disks, or deliver it electronically to them. I asked Captain Jack once, about including Tk in Camelbox, but there was some problem. Anyways, you can convert most Tk apps to a Gtk2 app, and you probably should look at ActiveState's Tkx and ActivePerl. The original allure of Tk on Windows was that ActivePerl included a running Tk.... but no more.....ActiveState got tired of waiting for Tk to modernize, and spun off their own....Tkx.... so why not write in Tkx?..... it's probably better for you on Window's platforms.... they probably have an installer for you app too. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku	[reply]
Re^4: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 08:16 UTC
Re^5: How do you distribute your Perl application to your customers? by zentara (Archbishop) on Jan 12, 2010 at 12:17 UTC
Some notes below your chosen depth have not been shown here
Re^2: How do you distribute your Perl application to your customers? by jeffreyray (Sexton) on Jan 12, 2010 at 02:01 UTC
I use camelbox as well. It comes with the option to install pp. Pack your application with this command: `pp --gui --icon hello.ico -o out.exe hello.pl` [download]	[reply] [d/l]
Re^3: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 08:21 UTC
I installed pp and I am trying very hard to do use it (see my response to Corion) but for various reasons I struggle to succeed. It is a simple task for small programs and should be for larger ones too, but dependencies come in the way and make it quite difficult to achieve.	[reply]
Re^4: How do you distribute your Perl application to your customers? by marto (Cardinal) on Jan 12, 2010 at 10:54 UTC
Re^5: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 13:32 UTC
Some notes below your chosen depth have not been shown here
Re^3: How do you distribute your Perl application to your customers? by Anonymous Monk on Dec 10, 2018 at 12:20 UTC
Many thanks for sharing, Its works great for me and myself started gaming with it.	[reply]
Re: How do you distribute your Perl application to your customers? by JavaFan (Canon) on Jan 11, 2010 at 11:53 UTC
I would like to know your way of distributing your Perl application to your customers without using par and pp. Be there, done that (although not on Windows, but on Solaris in an era Perl wasn't distributed with it). I just compiled a perl, stuck it in the tarball of the rest of the application, and made sure the appropriate `use lib` calls were done before using anything. Clients could install the tarball anywhere - an environment variable was used to point to the top directory of the tarball install.	[reply] [d/l]
Re^2: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 11, 2010 at 14:22 UTC
This sounds like you enjoyed it a lot! :-) This is exactly what I thought about before running across PAR::Packer. What did you do with the additional non-core modules? Did you tarball them too? Thanks!	[reply]
Re^3: How do you distribute your Perl application to your customers? by JavaFan (Canon) on Jan 11, 2010 at 16:34 UTC
I didn't need any non-core modules, but if I had, and gotten permission to distribute them, it would have trivial to put them in them somewhere in the tarball. (tarball we distributed then was several hundreds of Mb large, far larger than a perl distro at that time). There wasn't much enjoyment though - it was just work.	[reply]
Re^4: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 07:46 UTC
Re^5: How do you distribute your Perl application to your customers? by JavaFan (Canon) on Jan 12, 2010 at 10:51 UTC
Re: How do you distribute your Perl application to your customers? by kennethk (Abbot) on Jan 11, 2010 at 15:45 UTC
Another possibility may be using ActiveState's Perl Dev Kit, which builds an independent executable for you. Pay software, $$$.	[reply]
Re^2: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 08:23 UTC
Yes, as Corion pointed out, this is definately on my wishlist for the next project.	[reply]
Re: How do you distribute your Perl application to your customers? by afoken (Chancellor) on Jan 12, 2010 at 10:48 UTC
Some time ago, when Strawberry was nothing more that a sweet idea, and ActivePerl was the only Perl available for Windows (not counting cygwin), I took a version of ActivePerl, which, at that time, still used perl to install itself. I modified the installation routine to run without prompting, and stuffed it all into a self-extracting ZIP archive. I also bundled some packages, like DBD::ODBC and DBD::Oracle, and of course the application itself, and installed them after having set up perl, all from within the installation script. Yes, that looks ugly and was ugly, but still better than a manual installation. Today, I would use Strawberry Perl, the application itself, and perhaps a small part of CPAN, bundled in an InnoSetup package. BTW: You and your customer might think that there is no Perl installed. But when you install Oracle, you also install Perl. Unfortunately, that is often a very old Perl, and it is really hard to get rid of it. (Sure, you can simply delete it, but a clean uninstall also removes many other parts of Oracle. Explain the customer why you need to delete parts of Oracle.) Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^2: How do you distribute your Perl application to your customers? by kg (Acolyte) on Jan 12, 2010 at 13:25 UTC
I agree, a manual installation is not an option. I try to write something similar using NSIS. How did you cope with errors during the installation of Perl? Strawberry Perl, I might consider that approach if my schedule allows for it. It looks promising as far as a brief overview can tell. Oracle installing Perl. Cool. Thanks for sharing. :-)	[reply]
Re^3: How do you distribute your Perl application to your customers? by afoken (Chancellor) on Jan 12, 2010 at 15:10 UTC
I try to write something similar using NSIS. I've considered that, too, for a more recent project. But that lovely coding experience with elements of PHP and assembly looks more like Brainfuck. In fact, they should have better written "with the worst parts of assembly, PHP and the C preprocessor". Funny for golf and JAPHs, but not maintainable. InnoSetup is much cleaner, using a very nice Pascal implementation for scripting. How did you cope with errors during the installation of Perl? "Errors? What errors?" -- Well, I simplified the description of the installing process a litte bit. The installer explicitly warned that you need Administrator privileges. It invoked a batch file checking for an available perl before installing AS Perl. It refused to work with anything else, so we could not get errors due to other perls. The AS Perl setup was quite simple, just unpacking the ZIP was nearly sufficient, setting the few registry values luckily never failed (I think there was something like `or die` in the code), and after that, we had a known environment. Everything after that, including installing AP packages, could be handled by `eval {}` and `Win32::MsgBox`. In the worst case, you had a directory tree full of files that could not be installed properly. Removing that tree was sufficient to start a new, clean installation. To test the installer, I had a VMWare installation with Win2K in a VM, with a snapshot taken right after having set up Windows, Service Packs, and Databases. I copied the installer candidate into the VM, ran it, damaged a lot of stuff trying to imitate the worst possible user, and finally reverted to the VMWare snapshot. Wash, rinse, repeat until most bugs are gone. Strawberry Perl, I might consider that approach if my schedule allows for it. It looks promising as far as a brief overview can tell. It is. Really. Imagine you have a working CPAN right out of the box. And a sane C environment including compiler, linker, and a make variant. You can install any package from CPAN, including those with XS parts, without searching days for a PPM. The only little annoyance is that the standard installer has to install to a fixed path (C:\strawberry). There are variants of the installer for D:\strawberry and for a portable strawberry, but I haven't tested them. The standard was sufficient. :-) Oracle installing Perl. Cool. Thanks for sharing. :-) Not cool. At best, it's old and smells a little bit funny. But generally, it disturbs any other perl you want to use. And some parts of Oracle depend on scripts that were once generated by Perl scripts, so Oracles perl becomes part of the dependencies for a surprisingly big part of Oracle, just because you could want to re-generate those scripts. That's why it's very hard to get rid of Oracles perl using Oracles installer. We usually got away by having a big iron running Oracle and a rather small NT box running our application with just the bare Oracle client installed. And at that time, when Oracle delivered fast native applications instead of tons of Java junk, Perl wasn't bundled with Oracle, or at least not so much packages depended on it that it needed to be installed by default. Later, our clients demanded a cheeper server, that's when MS SQL Server support was forced into the application (and PostgreSQL was sorted out, because you could not pay for a license ...). But that's a different story, hard to tell without swearing and cursing. But practically, having MS SQL Server on the machine instead of Oracle solved the problem of Oracle's own perl. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]


Welcome to the Monastery
	PerlMonks