in reply to Post installation tests for a wrapper to a CLI utility?

I would set up as many VMs as possible, each one set up to continuously test the distribution against a different version of the CLI automatically. It's even easier if you can install multiple versions on one machine. You usually can't support all versions of a binary of course, but if you have decent coverage across a reasonable number of versions, things should go well.

In your Makefile.PL (or alternate build system setup file), you can do a check and just die() if the version of the CLI on the client system does not conform to one of the versions that your tests pass against. If the CLI has a --version flag for instance, this is trivially easy to support.

By the sounds of it, the CLI is something installed by the client and used in production, so I would loudly advise against (ie. don't do it!) copying in the new CLI onto a system. Instead, advise the installer of the distribution when you stop the install process that their version of the CLI is/can not be supported, and they need to upgrade, and display the version options they have.

Here's an example where I check for a binary (perlbrew or berrybrew depending on OS-type). I don't exit, I just warn that we'll install anyways, but the Perl "binaries" I'm about to install to use the distribution's modules simply won't work (because they won't work period and it'll be clear; this isn't a situation where it may partly work, but other things could cause detrimental issues. If it were, I'd hard exit).

Replies are listed 'Best First'.
Re^2: Post installation tests for a wrapper to a CLI utility?
by nysus (Parson) on Jan 31, 2018 at 07:09 UTC

    Thanks!

    Here's a 101 type question wrt Windows. I don't know much about Perl on Windows. I played around with ActiveState Perl like 15 years ago and that's about the extent of my knowledge. I do have access to a Windows 8 machine in VirtualBox which does not have Perl installed. What are the basic steps I need to take to install my module on that machine manually (it's not yet available on CPAN) to be able to run tests on it? Also, do I need to worry about differences between Window 8 and Windows 10 or any other flavor of Windows? And is Active State Perl still the standard? I know there is Strawberry Perl now.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]

      ActiveState has never been a standard. Make life easy on yourself, just install Strawberry, and use cpanm (cpanm . within the directory containing your module) to install & test your modules.

[reply]
[d/l]
[reply]

      Third marto, and second soonix - I moved to Strawberry back in 2008 and never looked back. I use Perl pretty much exclusively on Windows and unless a module is specifically written for *nix, Strawberry works great, installs from CPAN and just works. As a side note, the bundled GCC compiler let's me write and compile the (fairly small amount) of C programming I do.

[reply]
      This group is heavily biased towards Strawberry. I am still using ActivePerl as do some other Monks. ActivePerl is certainly not a "standard". I don't think that Strawberry qualifies either. However, both will work just fine.

      I often write code that other folks need to run on their Windows machines. Some of these folks don't know much if anything at all about Perl and aren't used to working with a command line. The ActiveState installation process on Windows is straightforward and the latest incarnations work well. With ActivePerl, I can generate an XML package file. I give my user the command to run this file and result is that my installation is "cloned" - the user now has my entire dev environment via a single step. With a pre-compiled and tested ActiveState .ppd files, the installation goes quickly - the longest part is generating the local HTML documentation files.

      With ActiveState, you can install the ActiveState cpan module and this comes with the correct compiler to make "from scratch" binary compatible modules (perhaps including XS parts) to the standard distribution.

      Anway just saying in some situations, ActivePerl can work out well.

[reply]

In Section Seekers of Perl Wisdom