Soften "selectors in noarch" lint for some cases

[jaimergp]

In conda-forge/backports.strenum-feedstock#4, at commit conda-forge/backports.strenum-feedstock@68ddfe0, 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.

[jakirkham]

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...

1. Soften the linter
2. Add an option to skip lints on certain lines
3. Better understanding of the context when linting
4. Better recognition by conda-smithy when matrices are needed (or not)

[carterbox]

@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?

[jakirkham]

Yeah the top-level noarch is needed to generate the error

[duncanmmacleod]

Softening this requirement would also help with providing noarch: python for a single platform. See, e.g, conda-forge/htgettoken-feedstock#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.