sigmoid.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A social space for people researching, working with, or just interested in AI!

Server stats:

552
active users

#cran

0 posts0 participants0 posts today

Dear R developers and CRAN maintainers, I wonder if you can kindly help me understand how I should deal with the import of some packages and package functions. Despite reading "R Packages" (eg <r-pkgs.org/dependencies-mindse>) and "Writing R Extensions" (eg <cran.r-project.org/doc/manuals>), I'm still unsure how to deal with the following situation.

Suppose you have a package with the following requirements:

1. *One* function in your package, say "funA" requires a whole package, say PKGA. *However*, the function only uses PKGA in a separate (parallel::makeCluster) process. This function is fundamental to your package, in the sense that the user will surely use it at least once in their workflow.

2. Another function in your package, say "funB", requires two functions "aux1" and "aux2" from another package, say PKGB. The user might use this function, or maybe not. In your code (no parallel invocation), the functions are called with PKGB::aux1 etc.

3. The two functions "aux1" and "aux2" from PKGB are also available in PKGA. You'd like to be sure that the user can choose freely which ones they want in their workflow, alongside your package. In other words, no masking should take place a priori.

Given these conditions, what should NAMESPACE and DESCRIPTION contain? With Roxygen, where should I use @ import and @ importFrom? and what about usethis::use_import()?

Thank you very much for any tips or extra references to read!

Edit: for the moment, my solution has been to include PKGA, PKGB, and parallel in the Imports field of the DESCRIPTION file, but not to have these three packages in the NAMESPACE file as Import(). This seems to achieve what i want, but I'm not sure it's the "proper" solution.

r-pkgs.org10  Dependencies: Mindset and Background – R Packages (2e)Learn how to create a package, the fundamental unit of shareable, reusable, and reproducible R code.

Dependencies and reverse dependencies: Python vs. R: Julie Tibshirani reflects on how the #R ecosystem uniquely manages dependencies through reverse dependency checks on #CRAN. R’s approach comes at a cost to developers, but also fosters a culture of empathy and responsibility among package...
spatialists.ch/posts/2025/09/2 #GIS #GISchat #geospatial #SwissGIS

Spatialists – geospatial newsDependencies and reverse dependencies: Python vs. R – Spatialists – geospatial news
More from Spatialists

Problems with CRAN during R installation Ubuntu:

To reproduce the error:
sudo add-apt-repository "deb cloud.r-project.org/bin/linux/ $(lsb_release -cs)-cran40/"

Error message:
Repository: 'deb cloud.r-project.org/bin/linux/ plucky-cran40/'
404 Not Found [IP: 108.157.173.54 443]
E: The repository 'cloud.r-project.org/bin/linux/ plucky-cran40/ Release' does not have a Release file

Consequences:
If you don't add the CRAN repository,
sudo apt install r-base
will install the r-base old version

#CRAN #Rstats

cloud.r-project.orgUbuntu Packages For R - Brief Instructions

New #rstats github.com/e-kotov/gridmaker Creates Eurostat GISCO compatible and INSPIRE-compliant grids with IDs that look like ‘CRS3035RES1000mN3497000E4448000’ or ‘1kmN3497E4447’. Input can be sf, or bounding boxes. Output can be sf polygons, centroids, or just data.frame with grid cell coordinates. The resulting grids are always aligned to rounded coordinates as per INSPIRE requirements. No more downloading 1.5-2.6 GB files from Eurostat. Do you think this is ready to go on #CRAN?

So, #rstats package mlr3spatiotempcv got removed from CRAN because a dependency package of it got kicked earlier.

This package made it back to #cran 4 days before the deadline for mlr3spatiotempcv. However, checks continued to fail with the same reason of "package XY not being available" and eventually mlr3spatiotempcv was removed.

The maintainer of the dep package couldn't upload a new version for more than two weeks because CRAN was "on vacation".

Now I have to go through a resubmission process for basically nothing.

There must be a better process - or an alternative repository. (Yes, I know about R multiverse)

tandis que le CRAN organise la cohérence entre les différentes versions de ses packages, ce travail d'alignement fait malheureusement défaut dans Pypi, raison pour laquelle Bruno Rodrigues plaide pour un meilleur contrôle des packages dans PyPi sous l'aspect de leur interopérabilité avec les autres packages qu'il contient brodrigues.co/posts/2025-08-22 #Pypi #CRAN #DependencyHell

brodrigues.coPython needs its CRAN – Econometrics and Free Software

🎥 What is O-RAN, really?

O-RAN isn't just a buzzword — it's a structural shift in how we build radio access networks.

By moving away from proprietary, locked-in systems and toward open, cloud-native architectures, operators gain flexibility… but also inherit new risks.

At the beginning of this analysis, we lay the groundwork — defining what O-RAN is before unpacking the security implications throughout the session.

▶️ Watch the full webinar for the complete breakdown: app.getcontrast.io/register/p1

Following #rstats packages were maintained and are back on #CRAN now thanks to Andrej Spiess

- #dpcR, 2025-06-18, Digital PCR Analysis <10.32614/CRAN.package.dpcR>
- #MBmca, 2025-06-11, Nucleic Acid Melting Curve Analysis (journal.r-project.org/articles)
- #qpcR, 2025-06-10, Modelling and Analysis of Real-Time PCR Data <doi10.1093/bioinformatics/btn227>
- #PCRedux, 2025-06-13, Quantitative #PCR (#qPCR) Data Mining and Machine Learning Toolkit as Described in <doi:10.21105/Joss.04407>