conda_build_config variables have different types in selector expressions and JINJA expressions

[msentissi]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

CBC variables will be strings in JINJA Expressions no matter what type they are in the CBC file. In Selector Expressions, they will be "coerced into a reasonable type", again independent of the type chosen in the CBC file. Other available variables (such as platform booleans: win, unix, etc..) are not affected by this.

Consider the following recipe:

package:
  name: var_is_int # [var == 1]
  name: var_is_str # [var == "1"]
  version: 1.0.0.{{ var == 1 }}

source:
  url: https://github.com/conda-forge/test-feedstock/archive/refs/tags/v1.0.0.tar.gz
  sha256: 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

requirements:
  build:
    - python
    - numpy
  run:
    - python
    - numpy

test:
  commands:
    - python -c "import sys; print(sys.version)"
    - python -c "import numpy; print(numpy.__version__)"

And accompanying CBC file:

var:
  - "1"

OR

var:
  - 1

No matter the type chosen for var inr the CBC, conda render will produce:

package:
  name: var_is_int
  version: 1.0.0.False

In other words, var is always an int in the selector expression, and always a str in the JINJA expression.

Conda Info

Conda Config

Conda list

Additional Context

No response

[jsmolic]

I took a look at the code and noticed that in

conda-build/conda_build/metadata.py

Lines 204 to 215 in cc7bb53

	# here we try to do some type conversion for more intuitive usage. Otherwise,
	# values like 35 are strings by default, making relational operations confusing.
	# We also convert "True" and things like that to booleans.
	for k, v in config.variant.items():
	if k not in d:
	try:
	d[k] = int(v)
	except (TypeError, ValueError):
	if isinstance(v, str) and v.lower() in ("false", "true"):
	v = v.lower() == "true"
	d[k] = v
	return d

CBC variables are intentionally converted to int for selectors. The comment in the beginning explains the reasoning. I’m not sure if modifying this could have unforeseen side-effects across different feedstocks. Updating the Jinja expression in the above mentioned example to {{ (var | int) == 1 }} would yield 1.0.0.True. However, there is still a mismatch when var is defined as a string in CBC as it would be converted to int. Is there a specific feedstock where this issue is exhibited?

cc @jaimergp

[msentissi]

I'm not aware of any feedstocks where this behaviour is currently an issue, I simply discovered it by experimenting and found the JINJA-selector inconsistency surprising and a bit counter-intuitive. I do agree that the breadth of downstream effects of making a change to this mechanism now are difficult to determine.

[jaimergp]

We may need to simply acknowledge this as a known "issue" and close this ticket by updating the relevant documentation. WDYT @jsmolic @msentissi?