Incorrect test scope for linux

[ekomarova]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

After installing libiconv-1.17-hd590300_2 package in a clean conda environment and trying to execute

pkgs/libiconv-1.17-hd590300_2/info/test/run_test.sh

I get the following error:

jq: error: Could not open file conda/envs/libiconv/conda-meta/libiconv-1.17-.json: No such file or directory

The reason for this problem is that in an already packaged package, the following test https://github.com/conda-forge/libiconv-feedstock/blob/main/recipe/meta.yaml#L61 looks like this:

test_man_files=$(jq '.files[] | select( . | startswith("share/man"))' $CONDA_PREFIX/conda-meta/libiconv-1.17-${PKG_BUILD_STRING}.json)

That is, the variable ${PKG_BUILD_STRING} has not been replaced with a hash, therefore, in fact, the test always tries to find file libiconv-1.17-.json instead of libiconv-1.17-hd590300_2.json.
I'm not very good at solving such problems, but maybe it's just a syntax error and there should be something like:

- test_man_files=$(jq '.files[] | select( . | startswith("share/man"))' $CONDA_PREFIX/conda-meta/{{ PKG_NAME }}-{{ PKG_VERSION }}-{{ PKG_BUILD_STRING }}.json)  # [unix]

Installed packages

_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       2_gnu    conda-forge
bzip2                     1.0.8                hd590300_5    conda-forge
ca-certificates           2023.11.17           hbcca054_0    conda-forge
jq                        1.7.1                hd590300_0    conda-forge
libffi                    3.4.2                h7f98852_5    conda-forge
libgcc-ng                 13.2.0               h807b86a_3    conda-forge
libgomp                   13.2.0               h807b86a_3    conda-forge
libiconv                  1.17                 hd590300_2    conda-forge
libnsl                    2.0.1                hd590300_0    conda-forge
libsqlite                 3.44.2               h2797004_0    conda-forge
libstdcxx-ng              13.2.0               h7e041cc_3    conda-forge
libuuid                   2.38.1               h0b41bf4_0    conda-forge
libzlib                   1.2.13               hd590300_5    conda-forge
ncurses                   6.4                  h59595ed_2    conda-forge
oniguruma                 6.9.9                hd590300_0    conda-forge
openssl                   3.2.0                hd590300_1    conda-forge
python                    3.9.18               h4499717_0    internal_channel
readline                  8.2                  h8228510_1    conda-forge
tk                        8.6.13          noxft_h4845f30_101    conda-forge
tzdata                    2023d                h0c530f3_0    conda-forge
xz                        5.2.6                h166bdaf_0    conda-forge

Environment info

active environment : libiconv
    active env location : /localdisk/work/ekomarova/conda/envs/libiconv
            shell level : 2
       user config file : /home/ekomarova/.condarc
 populated config files : /home/ekomarova/.condarc
          conda version : 23.1.0
    conda-build version : not installed
         python version : 3.10.12.final.0
       virtual packages : __archspec=1=x86_64
                          __glibc=2.31=0
                          __linux=5.4.0=0
                          __unix=0=0
       base environment : /localdisk/work/ekomarova/conda  (writable)
      conda av data dir : /localdisk/work/ekomarova/conda/etc/conda
  conda av metadata url : None
           channel URLs :
          package cache : /localdisk/work/ekomarova/conda/pkgs
       envs directories : /localdisk/work/ekomarova/conda/envs
               platform : linux-64
             user-agent : conda/23.1.0 requests/2.31.0 CPython/3.10.12 Linux/5.4.0-166-generic ubuntu/20.04.4 glibc/2.31
                UID:GID : 19712:22002
             netrc file : None
           offline mode : False

[ocefpaf]

Does it make sense to run that test outside of the conda package build context? If so, yes, we need to capture that hash or rename that file. But I'm not sure if we need to run it outside of the build. (Please correct me b/c my use of libiconv is limited! I only package it so could satisfy some dependencies for other packages.)

[ekomarova]

As far as I understand, conda-forge has never tested the package outside of the build. And I guess many users don't really care about testing. I would say that this is an individual problem for such products, which, like us, supplies many packages and tests them in one environment. After all, here we are talking exclusively about the problem of testing, and not the package itself.
I could try to create a PR that will fix this, if conda-forge agrees to accept this change.

[ocefpaf]

I could try to create a PR that will fix this, if conda-forge agrees to accept this change.

Sure. Let's see what we can do to fix this. As long as we don't add some extra complexity or break the package, it is worth a shot :-)

[ekomarova]

When I try to replace:

{{ PKG_NAME }}-{{ PKG_VERSION }}-${PKG_BUILD_STRING}.json

with:

{{ PKG_NAME }}-{{ PKG_VERSION }}-{{ PKG_BUILD_STRING }}.json

I get the following:

$CONDA_PREFIX/conda-meta/libiconv-1.17-placeholder.json

Probably the variable PKG_BUILD_STRING cannot actually be used in this way, and the syntax seems to be correct. To be honest, I'm at a loss, it's not very clear how to fix this