Closed h-vetinari closed 6 months ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
I have looked through the changes of the previous PR and I cannot see any obvious difference in the meta.yaml
that could cause the run_exports
to not be produced. The last functioning build was 5 months ago so a lot has changed in the infrastructure. I have verified with the glib-feedstock that we have at least built a package yesterday that has a relevant (non-strong) run_exports.
I guess we should download the artifacts to be sure?
Maybe a conda build bug?
I think maybe we need to nest run exports under build for outputs. I wonder if doing things this old way is broken.
I think maybe we need to nest run exports under build for outputs. I wonder if doing things this old way is broken.
Going to investigate that locally, just waiting on a very long rerender to finish.
I think maybe we need to nest run exports under build for outputs. I wonder if doing things this old way is broken.
Yeah, that's probably it. The last PR introduced new build
key for the outputs and the top level run_exports
does not work and need a build: run_exports
key instead. To confirm, just try conda render recipe
on the following,
package:
name: foo
version: 3
build:
number: 0
outputs:
- name: bar
build:
skip: true # [osx]
run_exports:
- bar >=3
requirements:
host:
- zlib
- name: baz
run_exports:
- baz >=3
requirements:
host:
- zlib
and you'll see run_exports are missing on bar, but it does exist on baz.
Locally, the run_exports
look fine now.
Should we add a smithy lint for any run exports not under build?
Should we add a smithy lint for any run exports not under build?
Yes, that would be helpful.
Shall we merge?
Follow-up from #102, see here