Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> on the machines I have handy, the only one in which [Expect] appears in the
>> default Perl installation is macOS. (Huh, what's Apple doing out ahead
>> of the pack?) I'm pretty sure that Expect also relies on IO::Pty,
> Indeed, it does.
>> so it's a strictly worse dependency than what I've got here.
> If you have to install IO::Pty anyway, ISTM you can also install Expect.
My point is precisely that buildfarm owners *won't* have to install
IO::Pty; it comes in a default Perl install almost everywhere.
I'm afraid that's not true of Expect.
Now in both cases we could avoid raising the bar by allowing the
script to "skip" if the module isn't there. But I think we'd end up
with less coverage if we do that with Expect than with IO::Pty.
> IO::Pty documentation says that it is "mainly used by Expect", which is a
> clue that IO::Pty is not much better than Expect as a dependency.
You're just guessing, not looking at facts on the ground. I have looked
at RHEL, Fedora, Debian, FreeBSD, NetBSD, and OpenBSD. The only one
in which IO::Pty isn't in the standard Perl install is OpenBSD.
Well, actually, it's possible that on some of these boxes it was pulled
in by the IPC::Run package, as I have that installed on all of them.
But the point remains the same: almost nowhere will IO::Pty be a new
dependency for a buildfarm owner, whereas Expect will be a new dependency
almost everywhere.
(One reason I'm interested to push this sooner not later is to find
out what fraction of the TAP-test-running buildfarm critters do have
IO::Pty already. If it turns out not to be almost all of them, then
my assumptions are wrong and we could revisit this discussion.)
> For installation, "apt install libexpect-perl" did the trick for me. "cpan
> install Expect" should work as well on most setup.
I'm well aware of the mechanisms for installing nonstandard Perl modules,
thanks. It's a pain, as a general rule. The fact that the buildfarm
requires IPC::Run is a large barrier to entry, and I don't want to double
the pain by adding a second far-off-the-beaten-track dependency.
regards, tom lane
