Postgres perl module namespace

Andrew Dunstan <andrew@dunslane.net> writes:

While solving a problem with the Beta RPMs, I noticed that they export
our perl test modules as capabilities like this:

[andrew@f34 x86_64]$ rpm -q --provides -p
postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm | grep ^perl
perl(PostgresNode)
perl(PostgresVersion)
perl(RecursiveCopy)
perl(SimpleTee)
perl(TestLib)

I don't think we should be putting this stuff in a global namespace like
that. We should invent a namespace that's not likely to conflict with
other people, like, say, 'PostgreSQL::Test' to put these modules. That
would require moving some code around and adjusting a bunch of scripts,
but it would not be difficult. Maybe something to be done post-14?

Agreed that we ought to namespace these better. It looks to me like most
of these are several versions old. Given the lack of field complaints,
I'm content to wait for v15 for a fix, rather than treating it as an open
item for v14.

Meanwhile I would suggest that RPM maintainers exclude both requires and
provides for these five names.

+1

regards, tom lane

Hi,

On Thu, 2021-05-20 at 15:47 -0400, Andrew Dunstan wrote:

Meanwhile I would suggest that RPM maintainers exclude both requires
and provides for these five names.

Done, thanks. Will appear in next beta build.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 5/20/21 5:18 PM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

While solving a problem with the Beta RPMs, I noticed that they export
our perl test modules as capabilities like this:
[andrew@f34 x86_64]$ rpm -q --provides -p
postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm | grep ^perl
perl(PostgresNode)
perl(PostgresVersion)
perl(RecursiveCopy)
perl(SimpleTee)
perl(TestLib)
I don't think we should be putting this stuff in a global namespace like
that. We should invent a namespace that's not likely to conflict with
other people, like, say, 'PostgreSQL::Test' to put these modules. That
would require moving some code around and adjusting a bunch of scripts,
but it would not be difficult. Maybe something to be done post-14?

Agreed that we ought to namespace these better. It looks to me like most
of these are several versions old. Given the lack of field complaints,
I'm content to wait for v15 for a fix, rather than treating it as an open
item for v14.

So now the dev tree is open for v15 it's time to get back to this item.
I will undertake to do the work, once we get the bike-shedding part done.

I'll kick that off by suggesting we move all of these to the namespace
PgTest, and rename TestLib to Utils, so instead of

    use TestLib;
    use PostgresNode;

you would say

    use PgTest::Utils;
    use PgTest::PostgresNode;

cheers

andrew

--

Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:

I will undertake to do the work, once we get the bike-shedding part done.

I'll kick that off by suggesting we move all of these to the namespace
PgTest, and rename TestLib to Utils, so instead of
    use TestLib;
    use PostgresNode;
you would say
    use PgTest::Utils;
    use PgTest::PostgresNode;

Using both "Pg" and "Postgres" seems a bit inconsistent.
Maybe "PgTest::PgNode"?

More generally, I've never thought that "Node" was a great name
here; it's a very vague term. While we're renaming, maybe we
could change it to "PgTest::PgCluster" or the like?

regards, tom lane

On 2021-Aug-10, Andrew Dunstan wrote:

I'll kick that off by suggesting we move all of these to the namespace
PgTest, and rename TestLib to Utils, so [...] you would say

    use PgTest::Utils;
    use PgTest::PostgresNode;

WFM.

--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Hay que recordar que la existencia en el cosmos, y particularmente la
elaboración de civilizaciones dentro de él no son, por desgracia,
nada idílicas" (Ijon Tichy)

On 8/10/21 10:40 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I will undertake to do the work, once we get the bike-shedding part done.
I'll kick that off by suggesting we move all of these to the namespace
PgTest, and rename TestLib to Utils, so instead of
    use TestLib;
    use PostgresNode;
you would say
    use PgTest::Utils;
    use PgTest::PostgresNode;

Using both "Pg" and "Postgres" seems a bit inconsistent.
Maybe "PgTest::PgNode"?

More generally, I've never thought that "Node" was a great name
here; it's a very vague term. While we're renaming, maybe we
could change it to "PgTest::PgCluster" or the like?

I can live with that. I guess to be consistent we would also rename
PostgresVersion to PgVersion

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:

I can live with that. I guess to be consistent we would also rename
PostgresVersion to PgVersion

Are RewindTest.pm and SSLServer.pm things you are considering for a
renaming as well? It may be more consistent to put everything in the
same namespace if this move is done.
--
Michael

On Aug 10, 2021, at 7:10 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

use PgTest::Utils;
use PgTest::PostgresNode;

Checking CPAN, it seems there are three older modules with names starting with "Postgres":

Postgres
Postgres::Handler
Postgres::Handler::HTML

It would be confusing to combine official PostgreSQL modules with those third party ones, so perhaps we can claim the PostgreSQL namespace for official project modules. How about:

PostgreSQL::Test::Cluster
PostgreSQL::Test::Lib
PostgreSQL::Test::Utils

and then if we ever wanted to have official packages for non-test purposes, we could start another namespace under PostgreSQL.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Aug 11, 2021 at 9:37 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:

On Aug 10, 2021, at 7:10 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

use PgTest::Utils;
use PgTest::PostgresNode;

Checking CPAN, it seems there are three older modules with names starting with "Postgres":

Postgres
Postgres::Handler
Postgres::Handler::HTML

It would be confusing to combine official PostgreSQL modules with those third party ones, so perhaps we can claim the PostgreSQL namespace for official project modules. How about:

PostgreSQL::Test::Cluster
PostgreSQL::Test::Lib
PostgreSQL::Test::Utils

and then if we ever wanted to have official packages for non-test purposes, we could start another namespace under PostgreSQL.

Maybe it's me but I would find that more confusing. Also, to actually
claim PostgreSQL namespace, we would have to actually publish them on
CPAN right?

On 8/10/21 9:37 PM, Mark Dilger wrote:

On Aug 10, 2021, at 7:10 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

use PgTest::Utils;
use PgTest::PostgresNode;

Checking CPAN, it seems there are three older modules with names starting with "Postgres":

Postgres
Postgres::Handler
Postgres::Handler::HTML

It would be confusing to combine official PostgreSQL modules with those third party ones, so perhaps we can claim the PostgreSQL namespace for official project modules. How about:

PostgreSQL::Test::Cluster
PostgreSQL::Test::Lib
PostgreSQL::Test::Utils

and then if we ever wanted to have official packages for non-test purposes, we could start another namespace under PostgreSQL.

If we were publishing them on CPAN that would be reasonable. But we're
not, nor are we likely to, I believe. I'd rather not have to add two
level of directory hierarchy for this, and this also seems a bit
long-winded:

    my $node = PostgreSQL::Test::Cluster->new('nodename');

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Aug 10, 2021, at 7:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

If we were publishing them on CPAN that would be reasonable. But we're
not, nor are we likely to, I believe.

I'm now trying to understand the purpose of the renaming. I thought the problem was that RPM packagers wanted something that was unlikely to collide. Publishing on CPAN would be the way to claim the namespace.

What's the purpose of this idea then? If there isn't one, I'd rather just keep the current names.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 8/10/21 9:25 PM, Michael Paquier wrote:

On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:

I can live with that. I guess to be consistent we would also rename
PostgresVersion to PgVersion

Are RewindTest.pm and SSLServer.pm things you are considering for a
renaming as well? It may be more consistent to put everything in the
same namespace if this move is done.

It could be very easily done. But I doubt these will make their way into
packages, which is how this discussion started. There's good reason to
package src/test/perl, so you can use those modules to write TAP tests
for extensions. The same reasoning doesn't apply to SSLServer.pm and
RewindTest.pm.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 8/10/21 10:13 PM, Mark Dilger wrote:

On Aug 10, 2021, at 7:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

If we were publishing them on CPAN that would be reasonable. But we're
not, nor are we likely to, I believe.

I'm now trying to understand the purpose of the renaming. I thought the problem was that RPM packagers wanted something that was unlikely to collide. Publishing on CPAN would be the way to claim the namespace.

What's the purpose of this idea then? If there isn't one, I'd rather just keep the current names.

Yes we want them to be in a namespace where they are unlikely to collide
with anything else. No, you don't have to publish on CPAN to achieve that.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 8/10/21 10:26 PM, Andrew Dunstan wrote:

On 8/10/21 10:13 PM, Mark Dilger wrote:

On Aug 10, 2021, at 7:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

If we were publishing them on CPAN that would be reasonable. But we're
not, nor are we likely to, I believe.

I'm now trying to understand the purpose of the renaming. I thought the problem was that RPM packagers wanted something that was unlikely to collide. Publishing on CPAN would be the way to claim the namespace.

What's the purpose of this idea then? If there isn't one, I'd rather just keep the current names.

Yes we want them to be in a namespace where they are unlikely to collide
with anything else. No, you don't have to publish on CPAN to achieve that.

Incidentally, not publishing on CPAN was a major reason given a few
years ago for using fairly lax perlcritic policies. If we publish these
on CPAN now some people at least might want to revisit that decision.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On 2021-Aug-10, Andrew Dunstan wrote:

If we were publishing them on CPAN that would be reasonable. But we're
not, nor are we likely to, I believe. I'd rather not have to add two
level of directory hierarchy for this, and this also seems a bit
long-winded:

    my $node = PostgreSQL::Test::Cluster->new('nodename');

I'll recast my vote to make this line be

    my $node = PgTest::Cluster->new('nodename');

which seems succint enough. I could get behind PgTest::PgCluster too,
but having a second Pg there seems unnecessary.

--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I'll recast my vote to make this line be
    my $node = PgTest::Cluster->new('nodename');
which seems succint enough. I could get behind PgTest::PgCluster too,
but having a second Pg there seems unnecessary.

Either of those WFM.

regards, tom lane

On 8/11/21 9:30 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I'll recast my vote to make this line be
    my $node = PgTest::Cluster->new('nodename');
which seems succint enough. I could get behind PgTest::PgCluster too,
but having a second Pg there seems unnecessary.

Either of those WFM.

OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
remainder don't care.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan <andrew@dunslane.net> wrote:

OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
remainder don't care.

I'd have gone with something starting with Postgres:: ... but I don't care much.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:

On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan <andrew@dunslane.net> wrote:

OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
remainder don't care.

I'd have gone with something starting with Postgres:: ... but I don't care much.

PgTest seems like a better choice to me, as "Postgres" could be used
for other purposes than a testing framework, and the argument that
multiple paths makes things annoying for hackers is sensible.
--
Michael