linter cannot parse jinja conditionals

[minrk]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

petsc is failing to lint because of conda-incubator/conda-recipe-manager#258 which cannot handle {% if ... branches, or jinja syntax in general, it seems.

    {% if cuda_major >= 12 %}
    - cuda-cudart-dev
    - cuda-nvtx-dev
    - libcublas-dev
    - libcufft-dev
    - libcurand-dev
    - libcusolver-dev
    - libcusparse-dev
    {% endif %}

fails to parse with:

File ~/conda/lib/python3.11/site-packages/conda_recipe_manager/parser/recipe_reader.py:480, in RecipeReader.__init__(self, content)
    478     depth_to_pop = (cur_indent - new_indent) // TAB_SPACE_COUNT
    479     for _ in range(depth_to_pop):
--> 480         node_stack.pop()
    481 cur_indent = new_indent
    482 # Look at the stack to determine the parent Node and then append the current node to the new parent.

IndexError: pop from empty list

or

WARNING:conda_smithy.linter.lints:Error parsing recipe with conda-recipe-manager: IndexError('list index out of range')
Traceback (most recent call last):
  File "/Users/minrk/conda/lib/python3.11/site-packages/conda_smithy/linter/lints.py", line 1069, in lint_recipe_is_parsable
    RecipeParser(recipe_text)
  File "/Users/minrk/conda/lib/python3.11/site-packages/conda_recipe_manager/parser/recipe_reader.py", line 484, in __init__
    parent = node_stack[-1]
             ~~~~~~~~~~^^^^
IndexError: list index out of range

Installed packages

conda                     24.9.2          py311h267d04e_0    conda-forge
conda-build               24.9.0          py311h267d04e_0    conda-forge
conda-forge-feedstock-ops 0.8.1.dev1+gca4306c          pypi_0    pypi
conda-forge-pinning       2024.11.21.05.29.27      hd8ed1ab_0    conda-forge
conda-index               0.5.0              pyhd8ed1ab_0    conda-forge
conda-libmamba-solver     24.9.0             pyhd8ed1ab_0    conda-forge
conda-lock                2.5.7              pyhd8ed1ab_0    conda-forge
conda-package-handling    2.4.0              pyh7900ff3_0    conda-forge
conda-package-streaming   0.11.0             pyhd8ed1ab_0    conda-forge
conda-recipe-manager      0.3.4              pyhd8ed1ab_0    conda-forge
conda-smithy              3.44.8          unix_pyhd81877a_0    conda-forge
conda-souschef            2.2.3              pyhd8ed1ab_0    conda-forge
conda-verify              3.4.2              pyhd8ed1ab_0    conda-forge

Environment info

mamba version : 1.5.10
     active environment : None
            shell level : 0
       user config file : /Users/minrk/.condarc
 populated config files : /Users/minrk/conda/.condarc
                          /Users/minrk/.condarc
          conda version : 24.9.2
    conda-build version : 24.9.0
         python version : 3.11.10.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=m1
                          __conda=24.9.2=0
                          __osx=15.1.1=0
                          __unix=0=0
       base environment : /Users/minrk/conda  (writable)
      conda av data dir : /Users/minrk/conda/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/osx-arm64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /Users/minrk/conda/pkgs
                          /Users/minrk/.conda/pkgs
       envs directories : /Users/minrk/conda/envs
                          /Users/minrk/.conda/envs
               platform : osx-arm64
             user-agent : conda/24.9.2 requests/2.32.3 CPython/3.11.10 Darwin/24.1.0 OSX/15.1.1 solver/libmamba conda-libmamba-solver/24.9.0 libmambapy/1.5.10
                UID:GID : 501:20
             netrc file : /Users/minrk/.netrc
           offline mode : False

[minrk]

Looks like there are no plans to address this bug, which I think means conda-recipe-manager is probably not appropriate to be used in conda-smithy and we should probably be looking elsewhere for recipe parsing, since this wasn't a problem before.

[wolfv]

Would it be workable to use selectors instead?

E.g. - foo #[cuda_major >=12] (Assuming that works).
The parser should work fine with that.

[minrk]

selector syntax does not appear to work, I think because cuda_major is a derived value and selectors seem to be evaluated before{% set ...%} at the top. So to use selectors, each selector needs to derive the major version directly from build inputs, while jinja {% if works more clearly and correctly.

When we can switch to recipe.yaml, we'll have the much nicer if: one_check then: list-of-things syntax, which will make this easier.

[wolfv]

Ah, ok, sorry, I wasn't aware of the fact that this is a derived value. If you really wanted to, you could do arbitrary python stuff in the selectors and maybe get it to work, but not sure if that makes sense (e.g. # [int(cuda.split('.')[0]) >= 12]) :)

[minrk]

Yeah. Need to also handle the non-integer cuda version 'None', too, so it gets a bit messy, but I imagine it could be done.

I think I'll just stick with the jinja that's far simpler and clearer than the selectors and already works great in meta.yaml until we move to v1 recipe.yaml (version bump / migrator bot support is the only thing blocking me from doing this more broadly, I think).