I have a Windows 10 system with limited storage space - and am looking for an implementation of perl that will take up as little space on the disk as possible.
I've been using Strawberry Perl - which uses about 500 MB.
My perl needs are minimal, but I may need to install a couple of cpan modules.
I found a "Tiny Perl" on SourceForge - but it hasn't been touched in years - so I'm reluctant to even try it.
Can anyone recommend a good solution here?
Thanks.
The Perl installed with Strawberry Perl, including all core and vendor modules and a few I installed myself, weighs in at 140 MB. When you say it uses 500 MB, you're including the build toolchain required to install modules in your total (e.g. gmake, mingw, etc). This is something added by Strawberry and isn't part of Perl, and isn't required in day-to-day use of Perl.
Similarly, not all of that 140 MB is needed by everyone. A chunk of that is also part of the toolchain required for installing modules (e.g. ExtUtils::MakeMaker, etc).
To get a smaller footprint, you could build your own Perl, or keep only the perl/ subdir of a SP install, and surgically remove core modules you don't want from that.
For example, you could install SP (along with any modules you want) on a machine with sufficient disk space, then copy over just the perl/ subdir (minus the modules you want to omit) to the limited machine.
In determining what modules to remove, you could consult any of a number of linux distros that split Perl into a base package and the remainder.
Related
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.
Besides the 3 platforms mentioned (more, if you count the Linux variants), you really have a couple different problems:
Deployment of a standard known-good Perl executable and libraries (CPAN modules).
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!
You may wish to check out CAVA packager. It can deal with multiple scripts in a single package.
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I compile the perl DBI package on solaris 10 say SERVER1 with say perl 5.8.10 installed on it and create DBI.
Now I copy the above DBI.so and the DBI.pm files to another solaris SERVER2 machine with the same hardware and the same version of perl.
Can I be sure that the DBI package will run smoothly and I will not get any run-time errors in future ?
Please note that I dont have the flexibilty to install a C compiler SERVER2.
Hardware does not matter so much as you think, the operating system abstracts this away nicely. For binary compatibility, the minor version must match, so the other Perl must also be from the 5.8 series. (By the way, 5.8.9 was the last one, 5.8.10 does not exist.)
As you're talking about a dynamic library, the integration on the C level is much more important. Are the libraries referenced from the DBI.so compatible (e.g. libc.so has the same version on both machines)? Check with the ldd command.
In case of mismatches, you will not get run-time errors, but very obvious crashes at compile time when perl attempt to load DBI.
The answer is the same as in this question: How can I install Perl modules on a restricted server? -- install your modules and libraries on a system with the same architecture (using a special installation directory), then copy the modules over to your restricted system.
You'll need a C compiler somewhere (unless you can find pre-compiled binaries of the .so or .dll files you need), but it doesn't have to be on the intended target.
I've written any number of perl modules in the past, and more than a few stand-alone perl programs, but I've never released a multi-file perl program into the wild before.
I have a perl program that is almost at the beta stage and is going to be released open source. It requires a number of data files, as well as some external perl modules -- some I've written myself, and some from CPAN -- that I'll have to bundle with it so as to ensure that someone can just download my program and install it without worrying about hunting for obscure modules.
So, it sounds to me like I need to write an installer to copy all the files to standard locations so that a user can easily install everything. The trouble is, I have no idea what the standard practice would be for this. I have found lots of tutorials on perl module standards, but none on perl program standards.
Does anyone have any pointers to standard paths, installation proceedures, etc, for perl programs? This is going to be complicated by the fact that the program is multi-platform. I've been testing it in Linux, but its designed to work equally well in Windows.
Take a look at PAR and PAR::Packer. You can bundle all of your requirements (even non-Perl requirements) into one file. With PAR::Packer, the user doesn't even need to have Perl installed for it to work.
You might also look at how the various App::* distributions are setup.
The standard installers for modules (ExtUtils::MakeMaker, Module::Build, Module::Install) also work the same way for scripts.
Using such a standard Perl tool will help you to:
distribute your application on the
CPAN (and you'll benefit from
automated tests on various platforms
by CPAN Testers), and so your app
will be installable (with all its dependencies) from the CPAN
shell
help packagers of Linux/BSD distributions to make packages for your product