conda-incubator / conda-recipe-manager

A project for libraries and automated tools that manage and manipulate conda recipe files.
BSD 3-Clause "New" or "Revised" License
8 stars 5 forks source link

`convert` does not handle some jinja expressions #166

Open carterbox opened 4 days ago

carterbox commented 4 days ago

What happened?

The following jinja expressions are not converted correctly or cannot be converted automatically.

{% set version = "0.3.0" %}
{% set soversion = ".".join(version.split(".")[:3]) %}
{% set somajor = version.split(".")[0] %}

requirements:
  host:
    - {{ pin_subpackage("libnvpl-fft" ~ somajor ) }}

My understanding is that the correct conversion should be something like:

context:
 version: "0.3.0"
 soversion: ${{ ".".join(version.split(".")[:3]) }}
 somajor: ${{ version.split(".")[0] }}

requirements:
  host:
    - ${{ pin_subpackage("libnvpl-fft" ~ somajor ) }}

However, the following error is raised:

EXCEPTION: An exception occurred while parsing the recipe file
while constructing a mapping
  in "<unicode string>", line 1, column 3:
    - {{ pin_subpackage("libnvpl-fft"  ...
      ^
found unhashable key
  in "<unicode string>", line 1, column 4:
    - {{ pin_subpackage("libnvpl-fft" ~ ...
       ^
0 errors and 0 warnings were found.

So it seems that the conversion cannot handle the "~" string concatenation operation from jinja2.

Furthermore, the top context is converted as follows:

  version: 0.3.0
  soversion: "\"\".\".join(version | split(\".\")[:3])\""
  somajor: "\"version.split(\".\")[0]\""

Which, by my understanding, is incorrect because jinja expressions should be surrounded by "${{}}".

To Reproduce

Steps to reproduce the behavior:

Run conda-recipe-manager convert on the first yaml example in this issue.

Additional Details (please complete the following information):

conda-recipe-manager 0.2.1 pyhd8ed1ab_0 conda-forge ubuntu linux on WLS2

schuylermartin45 commented 4 days ago

Thanks for the bug report!

Unfortunately there are a ton of these kinds of JINJA statements that are supported by conda-build that we do not currently support. We'll need to look into this further.

We should also look into softer failure modes. It would be nice if a user could at least receive a partial conversion in a crash. But there are some crash scenarios that may be unrecoverable.