Re: Portability issues in TAP tests

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Portability issues in TAP tests
Дата
Msg-id 20140718052625.GA2231360@tornado.leadboat.com
обсуждение исходный текст
Ответ на Portability issues in TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Portability issues in TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Portability issues in TAP tests  (Christoph Berg <cb@df7cb.de>)
Список pgsql-hackers
On Thu, Jul 17, 2014 at 03:31:19PM -0400, Tom Lane wrote:
> My Salesforce colleagues have been complaining that the TAP tests added
> in 9.4 don't work terribly well for them.  I've been poking at this,
> and I believe this is a reasonably complete list of the problems:

> 3. Many of the tests depend on Test::More's "subtest" feature, which
> unfortunately is of rather recent vintage (2009 or so).  It's not present
> for example in RHEL6's version of Test::More, and presumably not in any
> older distros either.  I'm not sure if we should consider it acceptable
> to depend on this feature: it doesn't seem exactly critical, and if we
> continue to use it, there is approximately 0 chance that we'll ever be
> able to enable the TAP tests on many of the existing buildfarm members.

Installing a new version of one Perl module is well within the capabilities of
buildfarm owners.  Saving them the trouble, which in turn means more of them
actually activating the TAP tests, might justify the loss.  I'd be sad to see
the "subtest" use go away, but I lean toward thinking it's for the best.

From a technical standpoint, it would be nicest to bundle copies of Test::More
and IPC::Run for the test suites to use.  Unfortunately, their licenses are
more restrictive than the PostgreSQL license.  Complicating the license
situation of the PostgreSQL tarball more than cancels out the benefit.  A
tractable alternative is to give the buildfarm client an option to setup a
private installation of the necessary modules for itself.  It does feel like
cheating, though, to make the buildfarm client paper over a usability
challenge in the core distribution.  Not sure.

> In any case, as long as we depend on it, there had better be some cleaner
> response to older versions of Test::More than just blowing up.

+1 for, if nothing else, putting a version number in the "use Test::More"
statement of TestLib.

> 4. IPC::Run isn't installed by default on RHEL, and probably not on other
> distros either.  If there's a reasonably painless way to remove this
> dependency, it'd improve the portability of the tests.  This is lower
> priority than the previous items, for sure.

Perl 5.10 and later incorporate IPC::Cmd, a weaker counterpart to IPC::Run.
It looked promising as a replacement when I examined the matter briefly.  Why
do you estimate the priority of (4) well below the priority of (3)?


A minor point to add to your list:

5. The TAP suites don't work when $PWD contains spaces.

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip kumar
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Следующее
От: Amit Kapila
Дата:
Сообщение: option -T in pg_basebackup doesn't work on windows