How to reference relative to `$PREFIX` in `license_file`?
In Conda Forge R recipes, we follow a standard practice of capturing a copy of the shared license file found in r-base. For example, in schema v0, if an R package has License: MIT + file LICENSE then we translate this to:
about:
license: MIT
license_family: MIT
license_file:
- {{ environ["PREFIX"] }}/lib/R/share/licenses/MIT
- LICENSE
where LICENSE is found in the source directory (included in original tarball).
Error Observed
We now have some recipes attempting to use the new v1 schema, but it is unclear how to translate the {{ environ["PREFIX"] }}. For example, on r-easy.utils PR, trying the translating according to https://github.com/prefix-dev/rattler-build/pull/260, we have
Syntax
- ${{ env.get("PREFIX") }}/lib/R/share/licenses/MIT
Result
2025-03-28T17:36:22.8752900Z Adding in variants from /opt/conda/conda_build_config.yaml
2025-03-28T17:36:22.8756439Z Adding in variants from /home/conda/staged-recipes-copy/.ci_support/linux64.yaml
2025-03-28T17:36:22.9167221Z
2025-03-28T17:36:22.9170697Z ╭─ Finding outputs from recipe
2025-03-28T17:36:22.9172446Z │ Loading variant config file: "/tmp/tmp32hrtiq5"
2025-03-28T17:36:22.9277483Z │
2025-03-28T17:36:22.9280300Z ╰─────────────────── (took 0 seconds)
2025-03-28T17:36:22.9285709Z Error: × Failed to parse recipe
2025-03-28T17:36:22.9288071Z
2025-03-28T17:36:22.9288350Z Error:
2025-03-28T17:36:22.9288772Z × failed to render Jinja expression: invalid operation: Environment variable
2025-03-28T17:36:22.9289177Z │ PREFIX not found (in <string>:1)
2025-03-28T17:36:22.9289578Z ╭─[staged-recipes-copy/recipes/r-easy.utils/recipe.yaml:53:7]
2025-03-28T17:36:22.9289899Z 52 │ license_file:
2025-03-28T17:36:22.9290235Z 53 │ - ${{ env.get("PREFIX") }}/lib/R/share/licenses/MIT
2025-03-28T17:36:22.9290642Z · ────────────────────────┬────────────────────────
2025-03-28T17:36:22.9291041Z · ╰── invalid operation: Environment variable PREFIX not found
2025-03-28T17:36:22.9291595Z 54 │ - LICENSE
2025-03-28T17:36:22.9291837Z ╰────
Possibly Related
Maybe related to https://github.com/prefix-dev/rattler-build/issues/1439, which observed PREFIX as undefined.
As a workaround, in the build, you could copy the files from the prefix to the work dir?
E.g
cp $PREFIX/licenses/foobar.* $SRC_DIR/licenses/
Thanks for the quick reply. Yes, that can work. I.e., we could add to our boilerplate in bld.bat and build.sh to copy all the shared licenses. Not ideal, but doable.
I think the case we want to avoid is converting our now generic build scripts to something package specific.
Are there any plans to have PREFIX defined when the licenses are captured?
I would say we don't have concrete plans right now. It would also not be super hard to do. We just have to decide that we want it, I guess.
Just want to explicitly note that I would prefer this feature to copying in build scripts. Having a single expression that can handle shared license copying is cleaner than having coupled lines across multiple files.
I think the main design question is whether we want:
license_file:
source:
- my_license.txt
recipe_dir:
- license.txt
prefix:
- license-foobar.txt
Or whether we go with
license_file:
- ${{ RECIPE_DIR }}/foo/bar
- ${{ PREFIX }}/foo/license.txt
- ${{ SRC_DIR }}/foo/license.txt
Or if we continue doing what we are doing today, which is having a search order:
- first search SRC_DIR
- then search RECIPE_DIR
- and now we could add search $PREFIX
for the license file.
How about:
license_file:
- autodiscover.txt
- prefix: from-prefix.txt
- recipe-dir: from-recipe-dir.txt
- source: from-source-dir.txt
I guess I could live with this. In the tests section, we changed the schema a bit to use:
...
files:
source:
- myfile.txt
- tests/
- some/directory/pattern*.sh
recipe:
- extra-file.txt
...
Would multiple files from one context be
license_file:
- prefix:
- from-prefix-1.txt
- from-prefix-2.txt
or
license_file:
- prefix: from-prefix-1.txt
- prefix: from-prefix-2.txt
?
Personally, I have a preference for the explicit requirement of context with:
license_file:
source:
- my_license.txt
recipe:
- license.txt
prefix:
- license-foobar.txt
Not a huge problem, but I do see newer users trip up on autodiscover of licenses. While autodiscovery is deterministic, it isn't self-evident from an example, whereas this is.
It would indeed be:
license_file:
- prefix: from-prefix-1.txt
- prefix: from-prefix-2.txt
I think @wolfv s suggestion is also more in line with the rest of the recipe format so Id be happy to use that instead.
Adding new keys to the schema is not something all tools will necessarily support without a CEP. I'm not a fan of schema extensions outside of the CEPs.
We should also standardize what env vars are available and what is available in the jinja.
Given everything else, I'd prefer the jinja route here. Constantly adding extra keys to the yaml to cover random additional locations / edge cases seems like an anti-pattern.
Just adding ref to related PR: https://github.com/prefix-dev/rattler-build/pull/1648
This seems to be blocking (are there more blocks?) towards adoption of v1 R recipes. The PR mentioned by @mfansler seems to tackle it, but has stalled - what would be needed to move forwards with this?
I do want to pick this up again, but use ${{ PREFIX }} in the recipe file and then resolve that at "globbing time". Unfortunately that is a bit more involved...