Fixing r41 issue

[cofinoa]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[cofinoa]

@conda-forge-admin, please rerender

[cofinoa]

@conda-forge-admin, please rerender

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• Recipes should usually depend on libjpeg-turbo as opposed to jpeg for improved performance. For more information please see Switch to / provide libjpeg-turbo conda-forge.github.io#673.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mfansler]

The issue is not that a jpeg dependency is needed here - noarch R packages never need shared libraries in host. Rather r-jpeg exclusively used jpeg to supply libjpeg for all of its linux-64 R 4.1 builds on Conda Forge. When Conda Forge changed to libjpeg-turbo to supply libjpeg, it was only building R 4.2 and 4.3 for linux-64. Hence, there are no linux-64 R 4.1 builds of r-jpeg that work with the libjpeg-turbo library.

The error encountered is because some of the old r-jpeg builds didn't properly declare their dependencies in the metadata. See conda-forge/r-jpeg-feedstock#13.

The solution is to get a newer linux-64 R 4.1 r-jpeg build made.

However, the motivation here is not explicated. It has been pointed out previously that providing extended older R version support is not generally sustainable. Conda Forge currently builds for R 4.2 and 4.3, which some partial support for Windows where we can only build R 4.1. Outside of these, it is important to communicate why there is a need to use Conda Forge resources to generate out-of-cycle builds.

[cofinoa]

The motivation for extended support of R older versions is to provide reproducibility in R3.6, which is the older version supported. Migration to R>=4.0 it's on going but support for R3.6 it's still requested, and no decision has been yet made on which version of R>=4.0 will be become the reference for future releases.

This package (r-visualizer) it's part of the climate4R framework with many other packages and interdependencies should be taken in consideration. That means, if this package (r-visualizer) which is a core package it's not supported in R4.1 all its dependants won't.

I have just made a patch to support R4.1, but just to be considering that R4.1 it's been supported for the rest of packages.

From your comment, it's clear that for future releases/builds, R4.1 should be considered to be removed.