Horton

Thread

Commits

  1. Reindent Perl files with perltidy version 20170521.

  2. Change pgindent/README to specify that we use perltidy version 20170521.

  1. perltidy version

    Magnus Hagander <magnus@hagander.net> — 2018-03-02T11:40:30Z

    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.

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?

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

  2. Re: perltidy version

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2018-03-02T12:30:08Z

    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

  3. Re: perltidy version

    Magnus Hagander <magnus@hagander.net> — 2018-03-02T12:34:47Z

    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/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

  4. Re: perltidy version

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-02T14:13:51Z

    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

  5. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-03-02T14:53:41Z

    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

  6. Re: perltidy version

    Magnus Hagander <magnus@hagander.net> — 2018-03-02T15:01:13Z

    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/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

  7. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-03-02T15:49:13Z

    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

  8. Re: perltidy version

    Magnus Hagander <magnus@hagander.net> — 2018-03-03T18:03:04Z

    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/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

  9. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-03-03T23:03:30Z

    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

  10. Re: perltidy version

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2018-03-04T20:41:17Z

    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

  11. Re: perltidy version

    Daniel Gustafsson <daniel@yesql.se> — 2018-03-04T20:42:25Z

    > 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

  12. Re: perltidy version

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-03-05T13:53:44Z

    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

  13. Re: perltidy version

    Magnus Hagander <magnus@hagander.net> — 2018-03-05T14:02:07Z

    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/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

  14. Re: perltidy version

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2018-04-23T15:43:06Z

    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

  15. Re: perltidy version

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-04-23T15:58:41Z

    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

  16. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-04-23T16:40:00Z

    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

  17. Re: perltidy version

    Michael Paquier <michael@paquier.xyz> — 2018-04-23T23:57:58Z

    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

  18. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-04-25T16:35:16Z

    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

  19. Re: perltidy version

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-04-25T16:44:24Z

    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

  20. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-04-25T18:01:29Z

    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

  21. Re: perltidy version

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-04-25T18:23:05Z

    Tom Lane wrote:
> 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?

I do.

(I also tested the "cpan" install instructions, and they worked
flawlessly, ending up with the correct ~/perl5/bin/perltidy binary.)

Thanks!

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

  22. Re: perltidy version

    Tels <nospam-pg-abuse@bloodgate.com> — 2018-04-25T19:24:14Z

    Moin,

On Wed, April 25, 2018 12:35 pm, 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 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.

Linking to the author directory can be pretty confusing, because if a new
(co-)-maintainer releases something, it will end up not in this directory.

But it is possible to point to the specific version PG needs like so:

http://search.cpan.org/~shancock/Perl-Tidy-20170521/

That way visitor see the right version, but also have all the other data
and see all other (still existing) versions, if they want.

If that page is "more confusing" than a directory listing where you have
to pick the right file, or not, is of course debatable.

Regards,

Tels

  23. Re: perltidy version

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-04-25T20:12:16Z

    "Tels" <nospam-pg-abuse@bloodgate.com> writes:
> On Wed, April 25, 2018 12:35 pm, 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.

> Linking to the author directory can be pretty confusing, because if a new
> (co-)-maintainer releases something, it will end up not in this directory.

As long as we're pointing at a specific past release, this seems like not
much of a problem.  Also, if I understood correctly, we need to expose
the author name as part of the install-with-cpan recipe, so taking it
out of the other URL seems like little advantage.

			regards, tom lane