Reopen the discussion on stdlib jinja function (original) (raw)
What is the idea?
We had a discussion at todays conda-forge meeting about the recently merged stdlib jinja function.
The current state is that we would write a migrator that would add this function to all recipes that have a {{ compiler('c') }} in their text, as most (maybe not all) packages would want that.
However, this seems a little "noisy" from a user perspective as all of a sudden they need to add another odd jinja function, and they need to add it almost unconditionally to all recipes that use the compiler.
For that reason I would like to propose a modification that extends the functionality of the compiler jinja function to add more than one dependency (this might need some hackery in conda-build, admittedly).
The idea would be that the compiler function would also read the additional variant config keys and have a extra keyword argument to control the behavior.
For example
- {{ compiler('c') }} # uses the default `stdlib('c')`
- {{ compiler('c', stdlib='musl') }} # uses `musl_stdlib`
- {{ compiler('c', stdlib=False }} # disable stdlib injection
We also make this backwards compatible by ignoring any non-existent stdlib. E.g. if the conda_build_config.yaml doesn't define a c_stdlib we do not add anything.
The main problem is that we need to figure out if we can add two packages from a single Jinja function.