Policies for package name conflicts

[wlandau]

From @shikokuchuo:

Currently we check against CRAN when packages are initially contributed, but we should also think about how to deal with:

1. Packages with same name in different R-universes, both wanting to list in R-universe. Is it just first-come-first-served?
2. Packages established on R-Multiverse. Package of same name is later submitted to CRAN.
3. Packages that are taken off R-multiverse or CRAN. Probably need to reserve the name so that users don't end up installing a completely different package by mistake if we allow the name to be re-used.

For 3, the CRAN policy would be not to let package name re-use: https://stat.ethz.ch/pipermail/r-devel/2013-August/067264.html
Incidentally that post says that renaming packages should perhaps only be due to legal concerns over the name.

I wonder if we need human review of new submissions. If first-come-first-served, what's to stop an automated bot submitting a skeleton package and squatting on all the best 'real estate'.

The above comment in the context that I think we need to maintain (3) - which is reserve names even when a package is taken down. There are ways to work around, but that seems like the most frictionless with regards user expectations of how things currently work.

For (2) does anything happen if someone registers on CRAN a package under a name that has existed a long time on Github? It would be the same here.

We can make it easy to check names on R-Multiverse via the package. Not sure there's anything else we can do. Obviously our existing tenant will then have priority over the CRAN package. But could get confusing for users if different packages exist under the same name.

Could be a self-selection issue that sorts itself out - for a package to be registered under the same name means that the maintainer has not thoroughly checked, and consequently, the package is not likely to be of high quality / widely-used anyway.

[wlandau]

My reply:

We could flag a PR for manual review if:

• It attempts to register more than X packages.
• The same user already has Y open PRs.

We might consider automation that triggers retrospective reviews in those cases. A bot could detect a URL mismatch between CRAN and GitHub, then flag a reviewer to resolve a potential dispute. But I'm not sure which way we would prefer a priori. Maybe this is where we trust reviewers to mediate a resolution within their sub-community (i.e. spatial or Bayesian).

[wlandau]

From @shikokuchuo:

Speaking to Colin Gillespie of Jumping Rivers at R Dev Day at Imperial: we may want to consider string similarity for flagging packages for manual review. Potential for malicious packages registered with similar names e.g. lubidate. Then if the package is not found on CRAN, it hits our repo and can install something malicious. From his experience of PyPi.