Open jaimergp opened 4 months ago
Another case that could benefit from softening are recipes using multiple outputs
If some of the outputs involve C/C++ and some involve noarch: python
packages (using ctypes
or similar to bind), conda-smithy will add a Python matrix (even if the outputs
using python
all have noarch: python
). However this is wasteful as the extra builds are unneeded. To fix this, one needs to add noarch: python
to the top-level recipe (even if python
is not used outside of specific outputs
). While this fixes the python
matrix issue, any use of selectors results in a linter error
It would be nice in this case to do something like...
@jakirkham I maintain a multi-output recipe which has both cxx and python noarch outputs. I have not seen this linting message. Is it because I use the noarch label per-output instead of in the top-level?
Yeah the top-level noarch
is needed to generate the error
Softening this requirement would also help with providing noarch: python
for a single platform. See, e.g, https://github.com/conda-forge/htgettoken-feedstock/pull/23 where I propose to build a noarch: python
version of a library on Windows only, whereas on Unix we continue to install extra Unix-specific things. Perhaps this is just not a good way to solve that problem.
In https://github.com/conda-forge/backports.strenum-feedstock/pull/4, at commit https://github.com/conda-forge/backports.strenum-feedstock/pull/4/commits/68ddfe0bd2fe7322a1d164ded689025e71a84ce0, the linter was complaining about selectors. These selectors were using
conda_build_config.yaml
variables that indeed were available.I'm assuming the general "selectors & noarch are a no-go" is meant to prevent OS-specific selectors only, so in this cases it should be ok to allow it.
I also understand is tricky to tokenize an arbitrary Python expression and that the new recipe format won't have this issue, and in the meantime we can do it in Jinja. So low-prio for me, but I thought I would raise the issue just in case there's an obvious solution.