perltidy version

Magnus Hagander <magnus@hagander.net> writes:

Our instructions in src/tools/pgindent/README says to make sure we use
perltidy version v20090616. However, this version no longer appears to be
available for download on the link we provide -- the oldest one available
is 20140328.

It's available via MetaCPAN:
https://metacpan.org/release/SHANCOCK/Perl-Tidy-20090616

Which means it can be installed with 'cpanm Perl::Tidy@20090616' or
'cpan SHANCOCK/Perl-Tidy-20090616.tar.gz' (the latter requires a
BackPAN-inclusive mirror configured, e.g. cpan.metacpan.org).

Direct tarball download link:
https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/Perl-Tidy-20090616.tar.gz

Or directly from BackPAN (the MetaCPAN mirror includes BackPAN):
http://backpan.perl.org/authors/id/S/SH/SHANCOCK/Perl-Tidy-20090616.tar.gz

Is it perhaps time to move up to a newer version? Or failing that, perhaps
we need to host our own copy of the old version?

BackPAN keeps all distributions ever uploaded to CPAN, unless removal is
explicitly requested, e.g. for legal reasons, so there should be no need
to host it ourselves.

- ilmari
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law

On Fri, Mar 2, 2018 at 1:30 PM, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
wrote:

Magnus Hagander <magnus@hagander.net> writes:

Our instructions in src/tools/pgindent/README says to make sure we use
perltidy version v20090616. However, this version no longer appears to be
available for download on the link we provide -- the oldest one available
is 20140328.

It's available via MetaCPAN:
https://metacpan.org/release/SHANCOCK/Perl-Tidy-20090616

Which means it can be installed with 'cpanm Perl::Tidy@20090616' or
'cpan SHANCOCK/Perl-Tidy-20090616.tar.gz' (the latter requires a
BackPAN-inclusive mirror configured, e.g. cpan.metacpan.org).

Direct tarball download link:
https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/Perl-
Tidy-20090616.tar.gz

Or directly from BackPAN (the MetaCPAN mirror includes BackPAN):
http://backpan.perl.org/authors/id/S/SH/SHANCOCK/Perl-Tidy-20090616.tar.gz

Is it perhaps time to move up to a newer version? Or failing that,

perhaps

we need to host our own copy of the old version?

BackPAN keeps all distributions ever uploaded to CPAN, unless removal is
explicitly requested, e.g. for legal reasons, so there should be no need
to host it ourselves.

In that case, we should at least update our instructions for how to install
it. But that's definitely a better option than hosting our own copy.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Magnus Hagander wrote:

In that case, we should at least update our instructions for how to install
it. But that's definitely a better option than hosting our own copy.

But surely the idea of updating the version to use should be considered
further? Maybe they have even improved the output ;-) Has anyone
looked?

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Magnus Hagander wrote:

In that case, we should at least update our instructions for how to install
it. But that's definitely a better option than hosting our own copy.

But surely the idea of updating the version to use should be considered
further? Maybe they have even improved the output ;-) Has anyone
looked?

+1. We're not that far away from it being time to run pgindent/perltidy,
so now would be a good time to consider whether we like a newer version's
result better.

If we do decide to stick on the old version, then yes, improve the
pointer.

regards, tom lane

On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

Magnus Hagander wrote:

In that case, we should at least update our instructions for how to

install

it. But that's definitely a better option than hosting our own copy.

But surely the idea of updating the version to use should be considered
further? Maybe they have even improved the output ;-) Has anyone
looked?

+1. We're not that far away from it being time to run pgindent/perltidy,
so now would be a good time to consider whether we like a newer version's
result better.

If we do decide to stick on the old version, then yes, improve the
pointer.

For example, Debian ships with 20140328, which produces the attached diff.
I'm not sure if we want to go to whatever is a "common version on most
platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
has 20120701, 16.04 has 20140328, and current devel has 20140328. In
general there seems to be very little overlap there, except Debian and
Ubuntu covers the same versions.

(Note that this diff is against HEAD -- it's possible a perltidy run with
the current version would also generate a diff, I have not compared them to
each other)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

+1. We're not that far away from it being time to run pgindent/perltidy,
so now would be a good time to consider whether we like a newer version's
result better.

For example, Debian ships with 20140328, which produces the attached diff.
I'm not sure if we want to go to whatever is a "common version on most
platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
has 20120701, 16.04 has 20140328, and current devel has 20140328. In
general there seems to be very little overlap there, except Debian and
Ubuntu covers the same versions.

(Note that this diff is against HEAD -- it's possible a perltidy run with
the current version would also generate a diff, I have not compared them to
each other)

Yeah, perltidy 20090616 already produces a pretty substantial diff on
HEAD; attached.

regards, tom lane

On Fri, Mar 2, 2018 at 4:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

+1. We're not that far away from it being time to run

pgindent/perltidy,

so now would be a good time to consider whether we like a newer

version's

result better.

For example, Debian ships with 20140328, which produces the attached

diff.

I'm not sure if we want to go to whatever is a "common version on most
platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
has 20120701, 16.04 has 20140328, and current devel has 20140328. In
general there seems to be very little overlap there, except Debian and
Ubuntu covers the same versions.

(Note that this diff is against HEAD -- it's possible a perltidy run with
the current version would also generate a diff, I have not compared them

to

each other)

Yeah, perltidy 20090616 already produces a pretty substantial diff on
HEAD; attached.

Ah yeah, if I apply that one first, the diff from using 20140328 is much
smaller. Attached is that one, which means the difference between the two
perltidy versions.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Magnus Hagander <magnus@hagander.net> writes:

Ah yeah, if I apply that one first, the diff from using 20140328 is much
smaller. Attached is that one, which means the difference between the two
perltidy versions.

I'm hardly a Perl guru, so I'm not going to opine on whether these
changes are for the better or worse. They're definitely not very
extensive, though. If the folks here who do hack Perl a lot think
the 20140328 output is better, I'm fine with switching.

regards, tom lane

On Sun, Mar 4, 2018 at 9:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Ah yeah, if I apply that one first, the diff from using 20140328 is much
smaller. Attached is that one, which means the difference between the two
perltidy versions.

I'm hardly a Perl guru, so I'm not going to opine on whether these
changes are for the better or worse. They're definitely not very
extensive, though. If the folks here who do hack Perl a lot think
the 20140328 output is better, I'm fine with switching.

It's a bit hard to tell just looking at the patch, but some of the
removal of leading whitespace looks a bit unfortunate (.e.g. genbki,
duplicate_oids). Maybe it would OK when applied. One thing I have
found is that string literals need to be broken up to less than the
line length or modern perltidy will happily realign them to the start
of the line regardless of other settings. I see what looks like some
evidence of that here.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 04 Mar 2018, at 00:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Ah yeah, if I apply that one first, the diff from using 20140328 is much
smaller. Attached is that one, which means the difference between the two
perltidy versions.

I'm hardly a Perl guru, so I'm not going to opine on whether these
changes are for the better or worse. They're definitely not very
extensive, though. If the folks here who do hack Perl a lot think
the 20140328 output is better, I'm fine with switching.

The 20140328 format is, IMHO, better in enough ways that I’d recommend
switching. The fact that it makes download for users, and documentation
writing for the project, easier is another good thing. +1 for going ti
20140328.

cheers ./daniel

Magnus Hagander wrote:

For example, Debian ships with 20140328, which produces the attached diff.
I'm not sure if we want to go to whatever is a "common version on most
platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
has 20120701, 16.04 has 20140328, and current devel has 20140328. In
general there seems to be very little overlap there, except Debian and
Ubuntu covers the same versions.

here's the changelog
https://metacpan.org/source/SHANCOCK/Perl-Tidy-20180220/CHANGES

The wikipedia page claims that the latest stable release is 20160302,
but that seems to be just because the page is out of date (last update
is before the following 2017-05 release)

It's hard to form an opinion based on this. I don't think picking one
because of its availability in some distribution is useful, since almost
everyone is going to have to download a custom one anyway, whichever
distribution we pick -- unless it's mine, of course, hah.

I think we should just pick some recent one and use it for X years; use
that one for all backbranches. I propose X=3. I propose 20170521
(newer ones seem to cater for stuff that I think we mostly don't use).

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Mon, Mar 5, 2018 at 2:53 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

Magnus Hagander wrote:

For example, Debian ships with 20140328, which produces the attached

diff.

I'm not sure if we want to go to whatever is a "common version on most
platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
has 20120701, 16.04 has 20140328, and current devel has 20140328. In
general there seems to be very little overlap there, except Debian and
Ubuntu covers the same versions.

here's the changelog
https://metacpan.org/source/SHANCOCK/Perl-Tidy-20180220/CHANGES

The wikipedia page claims that the latest stable release is 20160302,
but that seems to be just because the page is out of date (last update
is before the following 2017-05 release)

It's hard to form an opinion based on this. I don't think picking one
because of its availability in some distribution is useful, since almost
everyone is going to have to download a custom one anyway, whichever
distribution we pick -- unless it's mine, of course, hah.

I think we should just pick some recent one and use it for X years; use
that one for all backbranches. I propose X=3. I propose 20170521
(newer ones seem to cater for stuff that I think we mostly don't use).

20140328 seems to cover *most* versions. Another argument for that one
would be it's the one that we have on Borka, which is where we build the
official release tarballs, so we can use that as a stable fallback.

Those are both fairly weak arguments though. As long as we have good
instructions for how to make a local install of it that doesn't affect the
rest of the system, then that should not matter. And we need such
instructions anyway, since it won't be on every distribution.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 3/5/18 09:02, Magnus Hagander wrote:

I think we should just pick some recent one and use it for X years; use
that one for all backbranches.  I propose X=3.  I propose 20170521
(newer ones seem to cater for stuff that I think we mostly don't use).

20140328 seems to cover *most* versions. Another argument for that one
would be it's the one that we have on Borka, which is where we build the
official release tarballs, so we can use that as a stable fallback.

Those are both fairly weak arguments though. As long as we have good
instructions for how to make a local install of it that doesn't affect
the rest of the system, then that should not matter. And we need such
instructions anyway, since it won't be on every distribution. 

Did we decide on this?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut wrote:

On 3/5/18 09:02, Magnus Hagander wrote:

I think we should just pick some recent one and use it for X years; use
that one for all backbranches.� I propose X=3.� I propose 20170521
(newer ones seem to cater for stuff that I think we mostly don't use).

20140328 seems to cover *most* versions. Another argument for that one
would be it's the one that we have on Borka, which is where we build the
official release tarballs, so we can use that as a stable fallback.

Those are both fairly weak arguments though. As long as we have good
instructions for how to make a local install of it that doesn't affect
the rest of the system, then that should not matter. And we need such
instructions anyway, since it won't be on every distribution.�

Did we decide on this?

No agreement yet apparently :-)

I still vote we use 20170521 which is recent enough that we won't have
to change it in a few years.

I further vote that we change the URL in pgindent/README from
sourceforge to metacpan.org,
https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Peter Eisentraut wrote:

Did we decide on this?

No agreement yet apparently :-)

I still vote we use 20170521 which is recent enough that we won't have
to change it in a few years.

I further vote that we change the URL in pgindent/README from
sourceforge to metacpan.org,
https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod

I have no particular opinion on which version to use, but if we're going
to change for this cycle, it's time to do so. I'm intending to do the
initial pgindent run pretty soon ...

regards, tom lane

On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:

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

I still vote we use 20170521 which is recent enough that we won't have
to change it in a few years.

That's the version available on Debian sid, so from the prospective of
any Debian user this is a handy version to use when sending patches:
perltidy/unstable,now 20170521-1 all [installed]

I further vote that we change the URL in pgindent/README from
sourceforge to metacpan.org,
https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod

I have no particular opinion on which version to use, but if we're going
to change for this cycle, it's time to do so. I'm intending to do the
initial pgindent run pretty soon ...

I would vote for using a newer version with v11.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:

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

I still vote we use 20170521 which is recent enough that we won't have
to change it in a few years.

That's the version available on Debian sid, so from the prospective of
any Debian user this is a handy version to use when sending patches:
perltidy/unstable,now 20170521-1 all [installed]

I'm not hearing any objections or counterproposals, so let's go with
that version.

I further vote that we change the URL in pgindent/README from
sourceforge to metacpan.org,
https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod

Agreed on pointing to cpan, but that page is pretty confusing if you're
looking for a non-bleeding-edge version. I suggest linking to

https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/

which presents a handy directory listing. Or we could just point to

https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/Perl-Tidy-20170521.tar.gz

regards, tom lane

Tom Lane wrote:

Michael Paquier <michael@paquier.xyz> writes:

On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:

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

I further vote that we change the URL in pgindent/README from
sourceforge to metacpan.org,
https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod

Agreed on pointing to cpan, but that page is pretty confusing if you're
looking for a non-bleeding-edge version. I suggest linking to

https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/

which presents a handy directory listing.

Works for me. It's true that the other one is confusing unless you know
exactly where to click.

Or we could just point to

https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/Perl-Tidy-20170521.tar.gz

Well, that'd have to be updated whenever we change version, so I'd
rather have it go to the directory.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Tom Lane wrote:

Agreed on pointing to cpan, but that page is pretty confusing if you're
looking for a non-bleeding-edge version. I suggest linking to
https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/
which presents a handy directory listing.

Works for me. It's true that the other one is confusing unless you know
exactly where to click.

Done like that. Anyone want to cross-check that they get the same
results I did?

regards, tom lane