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.

[wlandau]

R-multiverse currently checks if a different package of the same name is on CRAN. Maybe that's a good thing to pause for in manual review, but as long as copyright is respected, nothing in our official policies prohibits hosting a package whose name coincidentally conflicts with that of a different package on CRAN.

I think the bigger concern is full transparency and clarity about the priorities of the different package repos. Jeroen once mentioned that install.packages(repos = c("https://production.r-multiverse.org", "https://cloud.r-project.org")) might not always prefer "https://production.r-multiverse.org", possibly depending on package versions (I can't recall the details).

[wlandau]

Maybe p3m could help with this by providing a unified link for R-multiverse + CRAN.

[noamross]

Do you also currently check against Bioconductor?

[wlandau]

Not currently, no.

[noamross]

Also regarding (3) Packages that are taken off R-multiverse or CRAN: How would this work for an author that wants to move from CRAN to Multiverse, or decides to host on Multiverse because the package is archived or no longer in compliance with CRAN or Bioconductor?

[wlandau]

I just realized most of this discussion took place before #78 or #110. I think the current snapshot model and potential p3m integration will help. For production, we are aiming for a unified repo URL that prefers the R-multiverse production snapshot and falls back on the analogous CRAN snapshot from the same day. This strategy is consistent with how R-universe performs checks, so it should serve the same set of compatible package versions that were tested. P3m integration might or might not happen though, and this would be tough to implement without it.

[wlandau]

When a package is removed from CRAN, I don't think R-multiverse needs to do anything specific. The next production snapshot is understood to be an interdependent system of packages and R together at a specific point in time. To use a package from production, we already recommend to use the versions of R and dependencies from that same production snapshot.

When a package is removed from R-multiverse, it shouldn't interfere with CRAN. I think the only concern would be what happens if a package of the same name is added back to R-multiverse at a later date. We should make sure the package goes through manual review. So I think we should require that moderators edit the existing package listing (with an informative note) rather than removing it. That way, any change will always trigger manual review. This is what we already plan to do to handle policy violations.

[wlandau]

Packages established on R-Multiverse. Package of same name is later submitted to CRAN.

It's hard to enforce that in an automated way. If we scrape both R-multiverse and CRAN and exclude the conflicts from R-multiverse production, then that would exclude packages deliberately hosted on both, which is I think a more common scenario. If we happen to hear specific reports of this though, a moderator could look into it.

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.

This seems like a good separate discussion.

[wlandau]

We should make sure the package goes through manual review. So I think we should require that moderators edit the existing package listing (with an informative note) rather than removing it. That way, any change will always trigger manual review. This is what we already plan to do to handle policy violations.

Added in r-multiverse/r-multiverse.github.io@6d452b3.

[wlandau]

I think we've worked through most of this. Will open a new discussion for string similarity.