Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objects loaded from file cannot be indexed into later #1423

Open
vyasr opened this issue Feb 11, 2025 · 3 comments
Open

Objects loaded from file cannot be indexed into later #1423

vyasr opened this issue Feb 11, 2025 · 3 comments

Comments

@vyasr
Copy link

vyasr commented Feb 11, 2025

When using the (experimental) load_from_file feature, it seems like the object data must be accessed immediately. The data cannot be stored into a context. I doubt that the issue is in load_from_file, it seems more likely to be a limitation of the Jinja subscripting support, but I wasn't sure of the best way to create an object inline that would represent this issue so it is likely that there is a simpler MWE available.

The problem can be demonstrated by copying these two files into a directory:

# pyproject.toml
[build-system]
build-backend = "setuptools.build_meta"
requires = [
    "setuptools",
]

[project]
name = "test"
version = "0.1.0"
# recipe.yaml
context:
  pyproject_data: ${{ load_from_file("pyproject.toml") }}
  # Uncomment these to test the different options below
  #name: ${{ pyproject_data.project.name }}
  #version: ${{ pyproject_data.project.version }}

package:
  # Does not work
  #name: ${{ pyproject_data.project.name }}
  #version: ${{ pyproject_data.project.version }}
  # Also does not work (assumes that the above
  #name: ${{ name }}
  #version: ${{ version }}
  # This works
  name: ${{ load_from_file("pyproject.toml").project.name }}
  version: ${{ load_from_file("pyproject.toml").project.version }}

source:
  path: .

build:
  number: 0
  script: |
    echo "The name is ${{ name }}"
    echo "The data is ${{ version }}"
@wolfv
Copy link
Member

wolfv commented Feb 12, 2025

Hey @vyasr - it's not actually an issue with Jinja in this case, but how we are doing things in the context (where we are forcing things to be either string, integer or boolean).

There is a PR to support lists in #1402.
We could similarly support maps in the context. I am just wondering wether it's a good idea...

@vyasr
Copy link
Author

vyasr commented Feb 12, 2025

Ah OK so basically this is the same issue as #971 and #1289.

@jakirkham
Copy link

Except we are asking for dictionaries/maps in addition to lists

Otherwise yes similar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants