Skip to content

Conversation

@mbargull
Copy link
Member

This adds support for jinja2 template parsing in construct.yaml. The error handling is essentially copied from conda-build. Unlike conda-build it has only basic jinja2 support, e.g., it is not possible to access environment variables etc.

Possible use case: Build an installer with Miniconda-esque version naming:

{% set py_major_ver = "3" %}
{% set conda_ver = "4.3.16" %}

{% version = conda_ver %}
{% name = "InstallMyConda" + py_major_ver %}

name: {{ name }}
version: {{ conda_ver }}

specs:
  - python >={{ py_major_ver }}
  - conda =={{ conda_ver }}
...

Note: The jinja2 processing is done after applying platform selectors.
Needs documentation (e.g., example and note above). If you find this PR viable, I could add some.

@loriab
Copy link

loriab commented Jul 15, 2017

+1 that this capability would be really helpful on multiple projects, if acceptable to the developers.

@msarahan
Copy link
Contributor

Merging, but I also agree that the jinja stuff here should remain simpler than it is in conda-build. I don't really see the need for the equivalent of conda-build 3's variants here.

@msarahan msarahan merged commit 2c8f669 into conda:master Aug 23, 2017
@github-actions
Copy link

Hi there, thank you for your contribution!

This pull request has been automatically locked because it has not had recent activity after being closed.

Please open a new issue or pull request if needed.

Thanks!

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Mar 19, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

locked [bot] locked due to inactivity

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants