Closed hadim closed 1 month ago
Trying to revamp https://github.com/conda-forge/staged-recipes/pull/17082
Hi! This is the friendly automated conda-forge-linting service.
I Failed to even lint the recipe, probably because of a conda-smithy
bug :cry:. This likely indicates a problem in your meta.yaml
, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge .
from the recipe directory.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11267788945.
@conda-forge/help-c-cpp ready for review
Hi! This is the staged-recipes linter and your PR looks excellent! :rocket:
@hmaarrfk LGTM for me, but please let me know if you think something is missing.
Looks fine, but to be honest, I'm not sure on where we stand with rattler recipes. Are we accepting them yet? or just building out infrastructure for them?
Looks fine, but to be honest, I'm not sure on where we stand with rattler recipes. Are we accepting them yet?
Yes we are (as of https://github.com/conda-forge/conda-forge-ci-setup-feedstock/pull/337). There's a few already
This might help as a temporary workaround for the ffmpeg issues: https://github.com/pytorch/audio/pull/3837
Thank you @Tobias-Fischer. What I don't get is why ffmpeg is not detected during the tests.
I won't have the time to wrap this PR in the short term, so if anyone needs it, go ahead. Otherwise, I might come back to it at a later time.
Any chance to give me write access to your fork @hadim?
Any chance to give me write access to your fork @hadim?
Should be good now.
@hmaarrfk @h-vetinari - do you think it would be acceptable if we disable ffmpeg integration? I saw it’s disabled in the torchvision feedstock. Same for sox which seems to cause issues.
Yes. The torchvision ffmpeg integration is stuck on ffmpeg 4 and was always broken IMO.
It is extremely hard to get right.
I don't really know how well they tested it upstream.
Yeah, fine by me to disable. Sox had some other issues (there's some patching involved that upstream explicitly ruled out IIRC), some references can be found in my old PR and on the sox feedstock
Well done @Tobias-Fischer. It looks like it's working.
The tests take about one hour per variant. Are you sure you want to take much time for building the package? I would maybe suggest downsizing the number of tests to be run. That would remove some pressure on the c-f CI but also reduce the testing loop of the feedstock itself.
But it's really up to you, and it's just a suggestion!
(also, do you mind removing me from the maintainer list, as I don't think I'll have the bandwidth to maintain it in the future?)
I'm not sure if this kind of test skip strategy is preferred to you: https://github.com/conda-forge/scikit-image-feedstock/blob/main/recipe/meta.yaml#L73
@hadim: Thanks for the feedback! The stress on CIs should not be too bad once it's a feedstock, as separate python versions will be built in separate CI jobs. That said, I'll temporarily use just a single python version from my next commit onward to reduce the stress here.
@hmaarrfk: Yes, the current solution is ugly. I don't know yet how we can do something like the strategy you linked to with the new recipe.yaml. @wolfv - do you have a suggestion?
Oh. I guess just maybe write one test per line in the test script?
that way we can read and understand each skip line by line.
For test skips, I definitely prefer the approach used in skimage (and elsewhere), where each component of the not (x or y or a)
string we're building gets a comment or reference about why that test us skipped
For test skips, I definitely prefer the approach used in skimage (and elsewhere), where each component of the
not (x or y or a)
string we're building gets a comment or reference about why that test us skipped
Isn’t that what we do now already? We group them into different failure cases.
@h-vetinari @hmaarrfk would you like to become maintainers as well?
no ;)
Given the work I did on this in https://github.com/conda-forge/staged-recipes/pull/17082, sure.
Yeah there are some secret ways that could make something like this possible ... I am not yet sure if I like it or not! :)
Note: this doesn't seem to work with the version of minijinja
we are currently using, but I can try to fix that asap:
context:
tests: |
${{
(
(['test1', 'test2', 'test3'] if ppc64le else []) +
['test1', 'test2']
) | join(" ")
}}
This would render to a (string) list. I am unsure about comments in Jinja expressions.
Otherwise one could also argue to write a more explicit "script" either in Python or in Bash that would give the list of tests to run. Downside: it's not in the recipe itself, upside it is a proper programming language.
If the tests run only on Unix you could also use something like:
script:
- echo "foo" > tests.txt
# run tests because bla bla
- if: ppc64le
then:
- echo "bar baz bing" >> tests.txt
- pytest bla $(cat tests.txt)
As another "saner" alternative. On Windows, sadly, syntax is always a bit different.
Options are:
Argh, sorry, acidentally slipped and closed the PR! Apologies 😞
And if you really want (although I am not sure we will keep this "feature") you can do:
context:
fuuu: |
{% set bla = "xxx" %}
${{ bla | upper }}
although I am not sure we will keep this "feature"
This kind of freedom would be very useful in some of the more complicated recipes that you've mostly descoped so far (AFAIU), because you care primarily about the bulk of simpler recipes for now. Is {% ... %}
still "pure YAML"? I cannot find it in the spec.
In any case, I'd like to not lose the ability to do commented test skips (at least talking about pytest -k
) within the recipe. Whether that works as before with some variables that get extended or whether the skips get saved into a skips.xyz
file (or whatever) doesn't matter to me, but I want it to be obvious from the recipe that there are test skips, what they are exactly, and the reasoning for each skip in a comment.
@h-vetinari yes, it is pure YAML because it is contained in a multi-line text block. :)
Also when I tested, the setted variable did not escape "outside" so maybe this can be allowed.
Does anyone have an idea why it can’t find nvcc for cuda 12? It looks in PREFIX instead of BUILD_PREFIX despite setting the suggested environment variable CUDACXX
I think this is finally ready for review :)
@hadim: Could you please remove the Draft label from the PR?
Note that cuda 11.8 failed with "No space left on device (os error 28)" which will not be an issue once it's converted to a feedstock with separate builds.
Thanks @hmaarrfk for the review!
Checklist
url
) rather than a repo (e.g.git_url
) is used in your recipe (see here for more details).