Hello Andriy and welcome to R-package-devel! On Fri, 19 Jan 2024 14:34:25 +0000 Protsak Andriy via R-package-devel <r-package-devel@r-project.org> wrote:
> to achieve this the initial focus is on exploring the possibility of > renaming the packages so that they share a common prefix, making it > easier for uses to locate them in the package list. CRAN package names are long-term identifiers. Assume that there are many users happy with the packages as they are. If you rename a package, they will have to patch their scripts and their own packages just to keep them working as before. Red Queen's race is not something people like to participate in. It is certainly not impossible to rename a package, but there has to be a very good reason to break backwards compatibility and assume a new name, while the old name stays in the archive, unavailable for new packages. Here are some past responses to similar questions: https://stat.ethz.ch/pipermail/r-package-devel/2022q2/008140.html https://stat.ethz.ch/pipermail/r-package-devel/2017q2/001678.html https://stat.ethz.ch/pipermail/r-package-devel/2015q3/000271.html > If you believe there are alternative strategies to achieve a similar > result, please feel free to share your perspective. There are approximately 20000 active packages on CRAN. Looking for useful packages by scanning a list of names will not be very effective. Better results can be achieved using tools like RSiteSearch <https://search.r-project.org/>. If you want a package to be more visible, request its addition to a Task View <https://cran.r-project.org/web/views/>. If some packages are related, make them link to each other in their documentation. David's options are all very good. > Additionally, I'm looking into the prospect of merging two packages > that contain similar functionalities. The aim is to create a more > comprehensive package by incorporation additional features and > ensuring seamless compatibility. The previous point about keeping backwards compatibility still stands. It should be possible to move all the functions to one package and then import() it from the other package. Both packages can then export() all functions, making them available to the dependencies of either package. Eventually, the skeleton package may grow packageStartupMessage()s letting the users know that it is deprecated and could they please use the other package instead. After a while, it should be possible to archive the skeleton package. But deprecation cycles should be long: for example, rgeos and rgdal took more than a year to retire <https://r-spatial.org/r/2022/04/12/evolution.html>. Or do you intend to come up with a completely new API? Beware of the second system effect (although it's certainly not unheard of for second system projects to succeed). The spatstat package went through the opposite process a few years ago: it grew too big and had to be split into multiple packages. Here's one of its maintainers sharing the experience: https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008557.html What is the nature of your final year project? If it can include technical writing, you could add well-written vignettes to the packages (only one of the CRAN packages maintained by people @uah.es has a vignette, and it's very terse). If it has to be mostly programming or maintenance of R packages, I'm out of ideas. Either way, good luck, and I hope your project succeeds! -- Best regards, Ivan ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
