Skip Menu |

This queue is for tickets about the Net-FullAuto CPAN distribution.

Report information
The Basics
Id: 69661
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Net-FullAuto

People
Owner: Brian.Kelly [...] fullautosoftware.net
Requestors: tour [...] jeroen.la
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.9945
Fixed in: 0.9948



Subject: Makefile.PL installs modules
Running Makefile.PL automatically installs missing modules, as shown in http://www.cpantesters.org/cpan/report/94e61408-b229-11e0-842c- a2d064958efa The convention for CPAN modules is that no modules get installed until the 'make install' step. Because of that, automated smokers can test a module by building all prerequisites and adding them to the @INC path, but without installing them. With your module, the automated smoke test will permanently install all dependencies. When running under CPANPLUS, could you leave installation of dependencies to CPANPLUS, by using a module like ExtUtils::MakeMaker or Module::Build? Alternatively, could you check for $ENV{'AUTOMATED_TESTING'}, and exit before installing modules, so that your distribution is skipped by the smokers?
I have added a conditional to exit FullAuto Install cleanly when a needed module is missing, cannot be "default" auto-installed via CPAN or CPANPLUS, and $ENV{'AUTOMATED_TESTING'} is detected. ALL modules are installed via CPAN or CPANPLUS, but some require shutting off the 'make test' and other manipulations to get them to build and/or install. That appears to be what you're objecting to. For instance, the IO::Pty module has tests that fail in Cygwin/Windows - even thought the module itself works perfectly in this environment. I *TRIED* numerous times to get the author to fix this - even submitting a patch that WAS actually included in a build (after about three months of waiting). But then in the very next version, the fix was excluded (probably due to poor version management) and I was back to square one. Again it took MONTHS before the fix was applied, and the fix was only available in one version, and for only a few weeks before it went missing in the next release of IO::Pty. I am willing to work with other authors, and have made attempts to contact them. But I've gotten poor responses and long delays. I'm not blaming them - for this is very nature of Open Source. Bottom line, if you don't like something, fix it "yourself". So I did - temporarily until the authors of the included modules get around to, or eventually gather enough incentive to, make the necessary repairs. Two other modules that go beyond default build procedures as supplied by Module::Build or ExtUtils::MakeMaker are BerkeleyDB and JSON. JSON inappropriately asks the user for an option in such a way that it can only be automatically included by temporarily manipulating the CPAN environment variables. Obviously this is not "supported" - but my options are limited. BerkeleyDB requires an installation of Berkeley DB. "That" requires a lot more than is offered by perl module utilities. I really want people to try and use "Net-FullAuto", but if they can't install it relatively easily, there is no way that is going to happen. I've even toyed with the idea of just including their code in Net- FullAuto's code base, but decided that was NOT an acceptable solution. On a naked host, FullAuto and all it's dependencies can take well over an HOUR to install. I simply can't have third party modules hard- stopping that installation with options that will only confuse most potential FullAuto users, or dying from fragile tests that are returning false negatives (at least from FullAuto's perspective). Most of these "false negatives" are occurring on Operating Systems that the authors probably never tested on - like Cygwin/Windows, which is REQUIRED for FullAuto to work on Windows. I am open to any other suggestions you might have.
From: tour [...] jeroen.la
Hi Brian, It sounds like you have put a lot of thought and work in this, and I can certainly appreciate your situation. I had no idea your installation procedure was doing so much extra work. Personally, authors have usually responded to my patches or bug reports, but I've certainly heard others echo your experiences. I suppose you are taking the same approach as many packagers for Linux distributions are taking: submit patches upstream, but patch the distribution until it is accepted. Sounds like a good approach. Are you prompting the user before starting to install all dependencies? I can't tell from the Makefile.PL. If not, it might be a good idea to do that, to make sure users are not surprised by everything that is installed. Other than that, I think they will be happy with the easy install. As for the automated testing: thanks. I'm happy now. Regards, Jeroen
Show quoted text
> As for the automated testing: thanks. I'm happy now. > > Regards, > Jeroen
Thanks Jeroen. Yes - the install does a LOT. It's taken me a YEAR to get it to work the way I want it too. If that sounds like a lot, FullAuto took TWELVE years to get right. I'm working on demo features now, so that folks can install FullAuto and see what it really does. Think of FullAuto as ONE perl for multiple hosts. Sitting on one host, FullAuto can connect to and fully manipulate via SSH and SFTP, anything on remote boxes. No daemon, or stub files required - JUST SSHD. That's it. On Windows Cygwin is necessary in order to supply the sshd. Even on Windows, full automation is possible. Entire farms of mixed operating system hosts can now be manipulated as ONE super computer - without ANY additional software needed on the remotes. I will be putting some Youtube videos together as well - to demonstrate it's almost endless capabilities. I will let you know when they are available. Thanks again!