The difference in the recipe produced by conda skeleton cran with conda-build 3 has some minor differences compared conda-build 2.

meta.yaml

The meta.yaml is similar and the current helper script should already work. One new line that I don't fully understand is:

build:
  merge_build_host: True  # [win]

According to the documentation:

--merge-build-host Merge the build and host directories, even when host section or compiler jinja2 is present

bld.bat

I don't think the helper script needs to edit bld.bat anymore. It is only 2 lines:

"%R%" CMD INSTALL --build .
IF %ERRORLEVEL% NEQ 0 exit 1

build.sh

The biggest change is in build.sh.

#!/bin/bash

if [[ $target_platform =~ linux.* ]] || [[ $target_platform == win-32 ]] || [[ $target_platform == win-64 ]] || [[ $target_platform == osx-64 ]]; then
  export DISABLE_AUTOBREW=1
  mv DESCRIPTION DESCRIPTION.old
  grep -v '^Priority: ' DESCRIPTION.old > DESCRIPTION
  $R CMD INSTALL --build .
else
  mkdir -p $PREFIX/lib/R/library/udunits2
  mv * $PREFIX/lib/R/library/udunits2
fi

I think we'll want to keep the line export DISABLE_AUTOBREW=1 since this prevents the R package from using homebrew to install package dependencies on macOS. I think we can remove the if/else since conda-forge is only building packages for linux, win-64, and osx-64 (I don't know what edge case this is catching).

Hey wonder Björn !

Is there a way to use your amazing conda R skeleton helper to create conda recipe from an archived CRAN R package? @Marie59 is trying to create new conda recipes (and having some trouble..) conda-forge/staged-recipes#18967

Cheers !!!

Thanks for this cool project! I came here from the instructions on conda-forge.org.

I just submitted a recipe for uptasticsearch (staged-recipes PR | CRAN page), and got the following complaint from conda-forge-linter:

I believe this is caused by this section, where conda-forge is looking {{ posix }} instead of {{posix}} in the template:

When I made that change (conda-forge/staged-recipes@771c3e9), the linting message was resolved.

The recipes generated with this skeleton include a section in build.sh covering the case where it include pre-build binaries and performs a relocation to the installation prefix.

Given conda-forge's policy to not include pre-built libraries, maybe this should be dropped completely?

Otherwise with the new compiler syntax, R won't be able to find the compiler.

How would we go about adding an R package that is currently on github? It is very common to use devtools::install_github and there are instances where some maintainers of R packages do not want to go down the path of getting it published on CRAN.

I would love to help build out the R ecosystem in conda, so any help/guidance will be much appreciated.

I'm using conda-build 3.18.10, and recipes generated by conda_r_skeleton_helper are failing with grep: DESCRIPTION.old: No such file or directory. The reason is here:

The targeted lines in the output of conda skeleton cran:

  mv DESCRIPTION DESCRIPTION.old
  grep -va '^Priority: ' DESCRIPTION.old > DESCRIPTION

So the first line gets removed, but the regex no longer matches the second line. PR is on the way.

Compare:

https://github.com/conda-forge/r-ape-feedstock/blob/master/recipe/meta.yaml vs https://github.com/AnacondaRecipes/r-ape-feedstock/blob/master/recipe/meta.yaml

AR version has "# The original CRAN metadata for this package was: .."

This block is deliberately emited and IMHO should not be elided in the aim (I guess?) of smaller recipes. It should not be elided because it alllows for reproduction of the recipe at a later date and also would ease implementing a conda skeleton --update feature (my thinking here is to do a diff of the old recipe (with our modifications) vs the old recipe recreated exactly from the DESCRIPTION, then apply those metadata diffs to the updated recipe.

The scripts are checking for a version prefix of '3', and refuse to run for anyone using the latest version of conda (24).

For packages with a GLP-2 license, conda_r_skeleton_helper generates a meta.yaml with license: GLP-2, but this failed the conda-forge linter with the error:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

A simple change to GPL-2.0-or-later instead of GLP-2 should be all that is needed.

Hi wonder Björn,

It appears that we have some trouble with the conda_r_skeleton_helper as using it, there is a message asking to install conda-build. Do you know if this can be due to a misconfig on our computers ? Or maybe there is something to care about on the helper side ?

As I noted in a this pull request, the most recent version of conda_r_skeleton_helper (since #49) will fail for any R package that does not have one of the ten exact licenses given here. Is this list really a comprehensive enumeration of all licenses which are acceptable for packages on Conda-Forge? Neither GPL-3.0-only nor GPL-3.0-or-later are included at all, and GPL-2.0-only and LGPL-2.0-only are included only in the context of LGPL-2.0-only OR GPL-2.0-only. I would interpret it more as a list of examples of well-formed SPDX licenses. Since R packages often do not use SPDX license strings, and in any case often have licenses other than those ten, this makes the tool all but useless.

I think a version which uses a genuine SPDX validator, and prompts the user for a replacement (possibly with suggestions based on partial text matching) if the existing license string is not valid SPDX, would be useful. Failing that, I think letting the Conda-Forge linter deal with SPDX validation is much more useful.

@bgruening do you think it would be useful to add this to bioconda-utils? I was about to update the bioconda docs to point to this repo, but then realized it would be helpful if it came already bundled as a CLI utility like bioconda-utils conda-forge-r pkgs.txt.

Then again it might be useful to keep this repo independent of bioconda-utils since it should track conda-forge policy rather than bioconda.

Thoughts?

Long-term the hope is that grayskull can replace these hacky scripts. The recent 2.0.0 release includes initial support for CRAN packages.

It shows potential, eg it already has a flag --strict-conda-forge, which was a long time dream of mine for conda skeleton cran, which instead was implemented piecemeal flag by flag. However, I don't think it's ready yet to replace these scripts. Most crucially, it doesn't yet handle the license files well, which is one of the main reasons these helper scripts have remained necessary over the years.

Implementation discussion in conda/grayskull#7, conda/grayskull#349, conda/grayskull#423

Current limitations: conda/grayskull#423 (comment), conda/grayskull#437

Right now this repository doesn't have any tests to catch incompatibilities with its upstream dependencies (conda-build, mainly). I think it would be valuable to set up some automated testing on the code to improve confidence in the new releases and to make the project more friendly to outside contributors.

One set of tests could be linting (flake8 / pycodestyle for Python, lintr for R) to catch minor style and code-quality issues like unused imports.

Another could involve a process that, for some hard-coded list of packages on CRAN, runs run.R and / or run.py and then checks the produced recipes with conda-smithy lint or something similar.

Given these tests, it would be useful to set up Travis CI or similar to run them on every change to the repo.

Hi,

I added some more lines, but don't know if it would work for everybody:

#!/bin/bash
set -o
set -e

for fn in `cat packages.txt`; do
    conda skeleton cran $fn
    sed -i '/^\s*#.*$/ d' $fn/meta.yaml
    sed -i '/^mv\s.*$/ d' $fn/build.sh
    sed -i '/^grep\s.*$/ d' $fn/build.sh
    sed -i '/^#\s.*$/ d' $fn/build.sh
    sed -i '/^@.*$/ d' $fn/bld.bat
    sed -i '/^$/{N;/^\n$/d;}' $fn/meta.yaml
    sed -i '/^$/{N;/^\n$/d;}' $fn/build.sh
    sed -i 's/ + file LICENSE//' $fn/meta.yaml
    sed -i 's/ \| file LICENSE//' $fn/meta.yaml
    if grep -lq "\- gcc"  $fn/meta.yaml ; then sed  -i 's/run:/run:\n   - libgcc               # [not win]/' $fn/meta.yaml ; fi
    # skip win builds
    sed -i 's/number: 0/number: 0\n  skip: true  # [win32]/g' $fn/meta.yaml

    sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' $fn/bld.bat
    sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' $fn/meta.yaml
    sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' $fn/build.sh
    if grep -lvq "extra:" $fn/meta.yaml ; then  cat extra.yaml >> $fn/meta.yaml ; fi
    perl -i -ne 'print if ! $last == $_; $last = $_' $fn/meta.yaml # remove duplicate lines one after another
    gedit $fn/meta.yaml
done


# if GCC add `libgcc # [not win]`
grep gcc r-*/* -R

Hi,
I was wondering whether the run.[py|R] scripts should identify the minimum version of R that is required by a package and include that in the meta.yaml that is produced.

For example, when I run.py for plotly, the minimum-required-versions are extracted for all imported packages (eg,ggplot2 / lazyeval) stated on it's CRAN page, but, although r-base is added to meta.yaml as a requirement, the minimum version of r-base (>=3.2.0) is not added to meta.yaml (and there are R versions that precede this available through anaconda).
All the best

conda/conda-build#2963

I have a r project with an Apache 2.0 license.

1. When using this helper, the license automatically pulled in becomes: "Apache License 2.0", which gets pulled into the license: recipe field

2. conda-forge-linter complains:
   a) "The recipe license should not include the word 'License'."
   b) "License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression."

3. fixed by changing to "Apache-2.0" (spdx identifiers are here: https://spdx.org/licenses/

Maybe conda_r_skeleton_helper could have a find/replace to translate the package license in CRAN to SPDX? This will prob be necessary for other licenses too.

Thanks!

Naive question, should I keep what is already present in the packages.txt
'''
r-tilegramsr
r-udunits2
r-usethis
'''
and add my package, or should I replace what is already there?

I used conda_r_skeleton_helper to create a recipe for the paco R package (my first conda-forge contribution). Running conda-build r-paco worked fine on my computer:

conda-build               3.10.3                   py36_0    conda-forge
osx v10.11.6

...however, when I submitted the PR to conda-forge, circleci generated the following error:

Setting build arch. This is only useful when pretending to be on another arch, such as for rendering necessary dependencies on a non-native arch. I trust that you know what you're doing.
rendering /home/conda/conda-recipes/r-paco for linux-64
Setting build platform. This is only useful when pretending to be on another platform, such as for rendering necessary dependencies on a non-native platform. I trust that you know what you're doing.
Computed that there are 1 distributions to build from 1 recipes
Resolved dependencies, will be built in the following order:
    r-paco-0.3.2-on-linux-64
Adding in variants from internal_defaults
INFO:conda_build.variants:Adding in variants from internal_defaults
Adding in variants from /opt/conda/conda_build_config.yaml
Adding in variants from config.variant
INFO:conda_build.variants:Adding in variants from /opt/conda/conda_build_config.yaml
INFO:conda_build.variants:Adding in variants from config.variant
Attempting to finalize metadata for r-paco
INFO:conda_build.metadata:Attempting to finalize metadata for r-paco
Undefined Jinja2 variables remain (['cran_mirror', 'cran_mirror']).  Please enable source downloading and try again.
Exited with code 1

Should I change {{'cran_mirror'}} to a specific mirror (eg., "https://cloud.r-project.org")? Should I add "cran_mirror" to the jinja template somehow?

I can't find any documentation on this issue, which is surprising, given that all users would probably run into this problem when using conda_r_skeleton_helper.

Our helper script currently creates recipes that fail the staged-recipes linter for any CRAN package that does not need to be compiled. This is because we added support for noarch in PR #24, which I did by suggestion from @isuruf. The purpose of this helper script is to create recipes according to conda-forge requirements, so we need to fix this. Here are the options I see:

1. Update the helper script to remove all lines with selectors for noarch recipes
2. Update the linter
3. Remove noarch support
4. Update the conda-build skeleton to remove selectors when --use-noarch-generic is set

Thoughts on how to proceed? @isuruf @bgruening @cbrueffer @dbast

Examples:

• A recipe I recently submitted that is currently failing the linter: conda-forge/staged-recipes#7128 (comment)
• A recipe where @dbast removed the noarch support in order to pass the staged-recipes linter

This skeleton helper adds a line like:
license_file: '{{ environ["PREFIX"] }}\R\share\licenses\GPL-3' # [win]
for GPL-2 and GPL-3 R packages. However, this path does not exist in the conda env. The solution is to either omit the line, or to package the license manually. Context and example at: conda-forge/r-bookdown-feedstock#4 (comment)

Happy to submit a PR, but should know:

1. Do we omit one or both lines? (or neither)
2. If we package manually, should we also adjust [not win] license entry as well? Seems we might as well.

My thinking for 2 is that we curl the license from https://cran.r-project.org/web/licenses/.

3. If we do this for GPL, should we do the same for MIT and other licenses at that page?

Hi, thank you for creating this resource! I tried following the instructions to get the R package BipartiteModularityMaximization onto conda-forge. However, the windows build failed (see conda-forge/staged-recipes#22460). I am sadly out of my depth here - would you be able to provide any thoughts on how I could fix this failure? I did not develop the R package, I'm only using it in one of my workflows.

Thanks in advance!