[Rd] URL checks
Martin Maechler
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Mon Jan 11 12:29:00 CET 2021
>>>>> Viechtbauer, Wolfgang (SP)
>>>>> on Mon, 11 Jan 2021 10:41:03 +0000 writes:
>>>>>>> Viechtbauer, Wolfgang (SP)
>>>>>>> on Fri, 8 Jan 2021 13:50:14 +0000 writes:
>>
>> > Instead of a separate file to store such a list, would it be an idea
>> to add versions of the \href{}{} and \url{} markup commands that are skipped
>> by the URL checks?
>> > Best,
>> > Wolfgang
>>
>> I think John Nash and you misunderstood -- or then I
>> misunderstood -- the original proposal:
>>
>> I've been understanding that there should be a "central repository" of URL
>> exceptions that is maintained by volunteers.
>>
>> And rather *not* that package authors should get ways to skip
>> URL checking..
>>
>> Martin
> Hi Martin,
> Kirill suggested: "A file inst/URL that lists all URLs where failures are allowed -- possibly with a list of the HTTP codes accepted for that link."
> So, if it is a file in inst/, then this sounds to me like this is part of the package and not part of some central repository.
> Best,
> Wolfgang
Dear Wolfgang,
you are right and indeed it's *me* who misunderstood.
But then I don't think it's a particularly good idea: From a
CRAN point of view it is important that URLs in documents it
hosts do not raise errors (*), hence the validity checking of URLs.
So, CRAN (and other repository hosts) would need another option
to still check all URLs .. and definitely would want to do that before
accepting a package and also regularly do such checks on a per
package basis in a way that it is reported as part of the CRAN checks of
the respective package, right?
So this will get envolved, ... and maybe it *is* good idea for a
Google Summer of Code (GSoC) project ... well *if* it that is
supervised by someone who's in close contact with CRAN or Bioc
maintainer teams.
Martin
--
*) Such URL errors then lead to e-mails or other reports of web
site checking engines reporting that you are hosting (too)
(many) web pages with invalid links.
More information about the R-devel
mailing list