Skip to content

Values of context variables can have different types depending on the underlying shell #1451

@gforsyth

Description

@gforsyth

I'm working on porting several conda-build recipes over to rattler-build and this particular quirk bit me a few times.

I have a context section like this:

context:
  version: ${{ env.get("RAPIDS_PACKAGE_VERSION") }}
  cuda_version: ${{ (env.get("RAPIDS_CUDA_VERSION") | split("."))[:2] | join(".") }}
  cuda_major: ${{ (env.get("RAPIDS_CUDA_VERSION") | split("."))[0] }}
  date_string: ${{ env.get("RAPIDS_DATE_STRING") }}
  head_rev: ${{ git.head_rev(".")[:8] }}

In the shell environment, representative values are things like RAPIDS_CUDA_VERSION=12.8.0 and RAPIDS_DATE_STRING=25026.

When I build this recipe locally, the value of cuda_major is '12' and date_string is '25026' -- however on a CI run (running bash but that's not the only factor) those variables get implicitly cast to int.

This is an issue, especially since we use them in selectors for choosing dependencies, so something like:

- if: cuda_major == "11"

suddenly isn't triggered because cuda_major=11 instead.

Given that shells, generally, have a very inconsistent view of the types of environment variables, is it possible to force all context variables that make use of env.get to be strings? And if someone wants an integer they can use | int?

For now, I'm forcing it myself like:

  cuda_major: '${{ (env.get("RAPIDS_CUDA_VERSION") | split("."))[0] }}'
  date_string: '${{ env.get("RAPIDS_DATE_STRING") }}'

but that's gross. Alternatively, maybe a str filter function to more cleanly force variables to always be strings?

Thanks!

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions